AD-A040  470 
UNCLASSIFIED 

|of3 


80E1N6  AEROSPACE  CO  SEATTLE  WASH  RESEARCH  ANO  ENGINE— ETC  F/0  5/5 
HUMAN  FACTORS  EN0INEERIN0  ANALYTIC  PROCESS  DEFINITION  ANO  CRITE—ETCCU) 

^ 75«.2«L.«25S!  * C SPRIN0ER  N62269-74-C-0693 

0180-18750-1 IH_ 


D180-18750-1 


HUMAN  FACTORS  ENGINEERING 
ANALYTIC  PROCESS  DEFINITION 
AND  CRITERION  DEVELOPMENT 
FOR 


^Computer 

Aided 

F unction-allocation 
E valuation 
Sjystem 


JANUARY  1976 


MTMFjE’I/ V&  AEROSPACE  COMPANY  • SEATTLE,  WASHINGTON 


[ON  STATEMENT  A 


Approved  for  public  releoMS 
Distribution  Unlimited 


D180-18750-1 


HUMAN  FACTORS  ENGINEERING 


ANALYTIC  PROCESS  DEFINITION 


CRITERION  DEVELOPMENT  FOR 
CAFES  a 


flIC 

WLT’IWSEJ 

KiJtftcAjm 


Prepared  Under  Contract 
N62269-74-C-$693  ) > 


Naval  Air  Development  Center 
Warminster,  Pennsylvania  18974 


Research  8 Engineering  Division 

BOEING  AEROSPACE  COMPANY 


ABSTRACT 


This  report  presents  results  of  a study  to;  (1)  develop  descriptive 
information  for  the  Human  Factors  Engineering  process  in  system  development," 
(2)  evaluate  the  Computer  Aided  Function-Allocation  Evaluation  System  (CAFES) 
for  ability  to  support  the  process  and  for  desirable  refinements;  and  (3)  Re- 
fine task  ind  equipment  data  requirements  for  CAFES.  In  the  resulting  *si ngle 
thread‘d  description  of  an  approach  to  performing  HFE  activities, ^requirements, 
methodology  and  examples  of  a manual  approach  are  presented.  These  are 
followed  by  brief  descriptions  of  CAFES  models  and  their  capability  to  support 
the  process.  Candidate  concepts  for  further  refinement  and  application  of 
CAFES  are  included. 
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1.0 


INTRODUCTION  AND  SUMMARY 


1.1  INTRODUCTION 

1.1.1  General 

Objectives  for  this  study  effort  were  to  develop  and  provide  an  explicit 
human  factors  engineering  (HFE)  analysis  procedure  that  would  apply  in 
using  the  Computer  Aided  Function-allocation  Evaluation  (CAFES)  computer 
models  (Ref  19  through  28).  These  objectives  also  included  the  intent  to 
refine  the  user  interface  definition  for  use  of  CAFES  submodels,  and  to  pro- 
vide a concept  for  initiating  storage  of  data  in  the  data  management  system. 
The  general  approach  for  achieving  the  objectives  was  to: 

o Refine  the  definition  of  the  human  factors  engineering  (HFE)  analytic 

process,  in  order  to  refine  related  CAFES  features  for  most  effective 
application  by  the  analyst 

o Provide  an  initial  definition  of  operator  _task  data  requirements, 
criterion  considerations,  and  organization/listing  for  use  with 
CAFES. 

o Provide  an  initial  definition  of  equipment  data  requirements,  and 
concept  organization/listing  for  use  with  CAFES. 

Major  elements  of  the  approach  followed  to  meet  study  objectives  were  to: 

1.  Summarize  HFE  objectives  in  system  development  programs. 

2.  Develop  a description  of  an  HFE  analytic  process  that  would  satisfy 
the  objectives,  including 

a.  Detailed  description  and  examples  for  a baseline  analytic  process. 

b.  Summary  information  on  HFE  methods  and  data  requirements. 

3.  Summarize  CAFES  features,  outputs  and  uses  in  supporting  the  baseline. 

4.  Identify  correlated  CAFES  data  requirements  and  desirable  refinements 
to  support  the  HFE  process. 
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1.1.2 


Background 


Conditions  leading  to  this  study  related  to  existing  CAFES  development  status, 
the  desire  to  initiate  near  term  applications,  and  the  need  to  define  a spec- 
ific HFE  approach  in  order  to  better  evaluate,  refine  and  use  the  CAFES  sub- 
models. Current  Development  status  provided  the  general  capability  to  support 
an  extremely  wide  range  of  potential  user  desires  and  applications.  However, 
the  overall  scope,  coverage  and  flexibility  were  so  broad  that  it  could  be  dif- 
ficult for  a new  user  to  comprehend  and  effectively  use  CAFES  during  an  initial 
exposure.  Accordingly,  it  was  desirable  to  develop  an  applications  approach 
that  could  be  used  as  an  outline  guide  by  an  analyst  in  developing  his  efforts, 
and  according  to  a concept  that  would  be  readily  supported  by  the  various 
CAFES  submodels,  i.e.,  the: 


DMS 

FAM 

WAN 

CAD 

CGE 

HOS 


Data  Management  System 
Functions  Allocation  Model 
Workload  Analysis  Model 
Computer  Aided  Design 
Crewstation  Geometry  Evaluation 
Human  Operator  Simulator 


Several  methodological  and  performance  limitations  related  to  the  HFE  state- 
of-art  were  instrumental  in  providing  the  impetus  for  this  study.  Some  form 
of  resolution  was  highly  desirable  in  order  for  CAFES  refinements  and  even- 
tual applications  to  be  most  effective.  First,  the  general  methodological 
framework  for  Human  Factors  Developments  and  for  CAFES  had  been  identified 
and  outlined  in  Military  Specification  MIL-H-46855,  "Human  Engineering 
Requirements  for  Military  Systems,  Equipment  and  Facilities."  However 
applications  experience  has  indicated  a wide  range  of  differences  existed  in 
interpretation,  philosophies  and  approaches;  technological  gaps  in  approaches 
that  are  employed,  and  methods  for  bridging  such  gaps;  and  inconsistencies  in 
both  methodology  and  associated  logic  structure.  Such  differences  inhibited 
most  effective  use  of  the  computer  aids.  At  a minimum,  some  interim  resolu- 
tion was  required  to  provide  an  analytic  procedure  as  well  as  to  provide  a 
framework  to  refine  the  CAFES  aids  for  better  support  to  the  HFE  analyst. 
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Most  specifically,  the  requirement  was  that  the  analytic  process  selected 
as  a concept  for  a system  development  program  would  precisely,  clearly  and 
systematically  lead  from  one  step  to  the  next,  and  would  provide  a concep- 
tual framework  paralleling  the  desirable  sequence  of  activities  for  most 
effective  use  of  CAFES  submodels. 

Secondly,  the  HFE  analyst  in  a new  development  program  has  often  been  con- 
fronted with  a dilemma.  On  the  one  hand,  effective  support  to  system  project 
needs  is  given  high  priority  and  requires  sufficient  flexibility,  freedom 
and  time  to  perform  such  studies  as  are  required  to  be  most  immediately  and 
fully  responsive.  On  the  other  hand,  there  is  a great  deal  of  effort 
involved  in  deriving  the  comprehensive,  time  consuming  analyses  that  could 
be  involved  for  a major  system  development  program.  Frequency,  much  of 
this  effort  is  redundant,  such  as  from  one  aircraft  system  to  the  next  (all 
aircraft  take  off,  climb,  descend,  land,  and  all  have  many  common  operating 
requirements).  In  practice,  the  dilemma  has  been  frequently  resolved  by 
taking  a calculated  risk  based  on  judgement  derived,  from  professional  expe- 
rience. However,  resulting  effectiveness  has  varied.  Alternatively,  a 
preliminary  concept  for  a baseline  analysis  reflecting  common  requirements 
could  be  developed  and  used  for  present  purposes.  A detailed  expansion 
could  later  be  stored  for  ready  modification  or  updating  to  tailor  the  data 
to  a specific  system. 

Third,  it  was  uncertain  as  to  how  to  best  provide  for  the  most  effective 
user  interface  to  enable  his  management  and  control  of  submodel  elements. 

It  was  desirable  that  the  analyst  be  efficiently  and  effectively  kept  in 
the  CAFES  loop  without  generating  undue, detailed  programmer  - type  activity 
leading  to  increased  analytical  workloads.  This  would  include  the  analyst's 
involvement  in:  developing  and  maintaining  an  overall  concept  for  the  develop- 
ing hardware  system;  reviewing,  updating  and  monitoring  "routine"  informa- 
tion to  detect  problem  areas  and  modify  information  as  required;  and  having 
ready  visibility  and  traceability  for  potentially  critical  problem  areas  in 
order  to  focus  attention  where  needed  to  resolve  such  problems.  It  would 
also  include  provision  for  the  analyst  to  develop  new  information  as  required, 
and  readily  incorporate  data  in  the  CAFES  structure. 
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It  was  considered  imperative  that  the  analyst  continually  participate  in 
task  development  and  that  his  capabilities  be  optimally  employed,  so  that 
the  submodels  provide  the  necessary  details,  organization  and  information 
to  reflect  the  most  effective  application  of  his  professional  experience, 
judgment,  skill,  intuition  and  insight.  Such  expertise  could  be  beneficially 
used  when  innovative  solutions  to  difficult  problems  are  needed.  This 
essential  and  critical  element  of  the  user  interface  was  to  be  retained  in 
the  automated  organization,  processing,  integration  and  presentation  of  data 
in  the  user-CAFES  interface  operations. 

Finally,  the  scope  of  potential  overall  HFE  applications  areas  vs  candidate 
requirements  for  input-output  data  and  interpretation  vs  available  data  was 
known  to  be  massive  and  complicated.  Additionally,  there  are  significant 
problems  in  determining  and  evaluating  compatibility  of  human  factors  data. 
There  was  even  a question  as  to  whether  data  has  to  be  compatible  or  com- 
parable for  intra-program  operations;  or  whether  it  would  be  sufficient  to 
inform  the  user/analyst  of  the  required  decision  and  available  data,  and 
then  require  him  to  take  the  appropriate  action. 

In  attacking  the  overall  scope  and  in  making  more  appropriate  decisions,  use 
of  HFE  system  analysis  techniques  has  been  demonstrated  to  provide  for  a 
systematic  organization  and  integration  of  the  morass  of  information,  and 
to  contribute  an  improved  overall  likelihood  of  success  for  the  HFE  process 
in  a system  development  program.  Basic  elements  of  methodology  that  existed 
have  been  manually  developed  and  correlated  to  provide  a systematic  step-by- 
step  procession  and  correlation  of  system  concepts,  missions  and  functions 
through  detailed  task  analysis,  task  timelines,  workload  and  design-development 


evaluations.  The  need  remained  to  clarify  the  rational  elements  within  each 
method  and  the  procedures  to  follow  between  steps  in  order  to  specify  a pro- 
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Accordingly,  the  overall  intent  for  this  study  report  has  been  to  produce 
a baseline  approach  for  HFE  efforts  that  can  be  used  in  an  initial  resolu- 
tion of  the  various  analytic  problem  areas  and  requirements  that  have  been 
indicated.  This  "single  thread"  manual  approach  was  intended  to  provide  a 
relatively  standard  procedure  that  could  be  readily  applied  as  one  concept 
for  using  CAFES. 

While  this  report  is  not  intended  to  develop  a full  blown  hardware  system 
development  concept,  it  provides  a sequence  of  applications  and  uses  of  the 
manual  process  in  sufficient  depth  to  be  used  as  a guide  in  CAFES  applica- 
tions. It  also  develops  and  outlines  the  manual  mode  and  concept  sufficientl 
to  support  later  detailing,  revision,  expansion  and  updating  for  a hardware 
system  and  for  associated  use  of  CAFES.  An  added  desire  for  the  approach  to 
be  outlined  herein  was  an  attempt  to  retain  adequate  flexibility  in  the 
approach  in  order  to  enhance  individual  preferences  and  methods. 

However,  the  most  important  overall  objective  was  to  establish  a framework 
for  using  CAFES,  for  refining  the  CAFES  concept  and  submodels  to  enhance 
utility,  and  for  initiating  storage  of  data.  'This  resulting  general  approach 
was  to: 

o Lay  out  a more  formalized  approach  for  HFE  processes  outlined  in 

MIL-H-46855  in  order  to  reflect  a relatively  precise  and  systematic 
methodology/model  for  developing  the  analyses, 
o Postulate  the  approach  for  a specific  system  (an  aircraft)  to  which 

CAFES  might  be  applied  in  future  efforts.  (Since  it  has  been  esti- 
mated that  over  80%  of  functional  requirements  are  common  between 
aircraft,  more  detailed  development  of  this  initial  approach  would 
lead  to  a reasonably  stable  base  for  future  use  and  would  readily 
transition  to  a specific  aircraft  concept  for  early  CAFES  applica- 
tions refinements.) 

o Evaluate  the  approach  adopted  in  terms  of:  (a)  implications  for  most 

beneficial  CAFES  submodel  refinements,  and  (b)  reverse  implications 
of  CAFES  on  the  HFE  approach. 
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o Determine  user  interface  implications  and  desirable  refinements  to 
enhance  overall  utility  of  the  submodels.  Include  consideration  of 
the  desirability  for  the  analyst  to  manage  and  use  pre-programmed 
information  by  review  and  exception,  or  by  expansion  and  modification. 
Also  consider  data  concept,  input-processing,  output  operations,  and 
interpretation . 

o Develop  an  initial  data  concept  and  organization-storage  scheme  for 
incorporating  data  in  the  CAFES  Data  Management  System  according  to 
a standard  format. 
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1.2 


SUMMARY 


This  report  covers  four  major  areas  relating  to  HFE  requirements,  methods, 
use  of  CAFES,  and  data  needs.  It  provides: 

o Summaries  of  the  HFE  role  and  responsibilities  in  a system  development 
program 

o Development  of  a pragmatic  methodology  for  performing  HFE  tasks  in  a 
system  development  program 

o Relationships  of  CAFES  submodels  and  operations  to  the  methodology 

o Outline  of  task  and  equipment  data  needs  to  accomplish  the  above. 

Human  factors  engineering  objectives  include  philosophy,  concepts  for  an 
overall  system  development  approach  and  the  typical  HFE  task  flow.  These 
are  correlated  with  specific  task  and  activity  requirements  imposed  by  the 
defense  Systems  Acquisition  Review  Council  and  by  specification  as  well  as 
necessary  integrations  of  operator  performance  variables.  The  scope  of 
coverage  is  demonstrated  to  be  so  large  as  to  require  an  extremely  systematic 
approach  for  comprehensive  coverage,  integration  and  detailed  development  of 
such  information. 

A baseline  process  methodology  is  developed  and  presented  to  reflect  an 
approach  to  performing  a systematic  progress  of  task  activities  in  HFE 
efforts  for  system  development.  The  methodology  employed  outlines  the 
approach  to  be  taken,  relates  the  steps  in  the  approach,  and  provides  for 
developing  the  systematic  and  integrated  progression  of  HFE  activities  to 
assure  that  sufficient  levels  of  detail  to  cover  all  potential  areas  of 
examination  have  been  included.  Examples  of  each  portion  of  the  developed 
methodology  are  carried  to  enough  detail  to  provide  the  human  factors  analyst 
with  guidance  in  application  of  the  methodology,  and  in  the  selection,  prepara 
tion,  use,  and  interpretation  of  results  when  using  CAFES  submodels.  The 
approach  is  tailored  toward  use  in  Naval  Weapons  Systems  development  but  it 
should  be  remembered  that  the  methodology  and  CAFES  submodels  have  wider  appli 
cability.  The  methodology  appears  to  be  applicable  to  non-weapons  sy terns 
development  (e.g.,  command  and  control;  air  traffice  control)  in  addition  to 
providing  an  indication  of  training,  manning,  and  procedures  requirements  for 
each  system. 
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2.0 


TECHNICAL  REPORT 


2.1  HUMAN  FACTORS  ENGINEERING  OBJECTIVES 

The  task  activities  performed  by  a Human  Factors  Engineering  Analyst  during 
a system  development  cycle  are  many  and  varied, and  are  constantly  changing 
in  scope  and  definition.  The  following  treatise  on  an  Analytic  Process 
Definition  and  Criteria  Development  is  an  attempt  to  initiate  a concept 
for  an  integrated  and  comprehensive  methodological  approach-that  can  use 
both  manual  and  computer  methods  to  provide  timely  and  relevant  Human  Factors 
inputs  to  a weapons  system  development.  The  treatise  is  by  no  means  an 
entirely  original  concept.  Background  material,  information  and  experience 
from  many  sources  and  knowledgeable  individuals  have  been  gathered  and 
synthesized  to  form  the  integrated  approach  to  be  presented. 


2.1.1 


General  Human  Factors  Engineering  (HFE)  Role 


The  Systems  Development  Process  encompasses  those  activities  necessary  to 
conceive,  define,  design  and  acquire  a system  capable  of  performing  tne 
desired  activities  within  specified  limits  of  acceptability.  HFE  activities 
are  part  of  this  definition  and  acquisition  cycle  since  people  are  an 
integral  part  of  the  systems.  System  operators  or  crewmen  are  included 
primarily  because  of  their  information  processing  capability,  their  decision 
making  capability,  their  ability  to  generate  small  forces  at  proper  times 
(i.e.,  control  movements,  switcli  actuations,  etc.)  as  controlling  functions 
for  implementation  of  subsystem  activities. 


The  entire  systems  development  activity  of  the  Human  Factors  Engineering 
analyst  is  dedicated  to  optimizing  the  capabilities  of  the  man-machine 
combination.  This  task  is  to  effect  maximum  information  processing  and 
control  in  system  operations,  within  the  required  time  and  accuracy  con- 
straints, and  to  provide  the  human  operator  with  the  interface  for  deter- 
mining and  effecting  necessary  changes  in  operation.  Fullest  achievement 
requires  analysis  and  confirmation  of  man-machine  interface  provisions  for 
all  subsystem  activities,  as  such  activities  fluctuate  in  normal  operations 
or  in  degraded  operations  throughout  the  system  mission. 
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2.1.1 


(Continued ) 


Accordingly,  and  during  a system  development,  HFE  technology  is  responsible 
for  organizing  information  and  performing  trade-offs  to  define  and  allocate 
functions  to  man  and  equipment,  and  for  defining:  control-display  require- 

ments, station  layout  and  arrangement,  provisions  for  effective  crew  operations 
and  performance,  workload  capability,  and  crew  environment/life  support 
requirements.  Another  element  of  data  applications  is  in  providing  task- 
equipment  inputs  for  training  and  procedural  considerations. 

In  turn,  large  quantities  of  pertinent  information  are  generated  during 
the  development  of  a weapons  system.  Over  a period  of  time  much  of  the 
data  is  lost,  and  only  limited  amounts  reach  a publication  which  may  be 
subsequently  recovered  by  interested  parties.  More  extensive  recording 
and  availability  of  such  information  would  have  long  term  benefits, 
particularly  in  early  stages  of  a new  system  development.  The  development 
of  a new  weapons  system  would  be  greatly  enhanced  by  accessibility  to 
historical  data  on  previously  examined  weapons  systems.  For  example, 
baseline  Functional  Flow  Block  Diagrams  could  provide  a wealth  of  infor- 
mation applicable  to  all  generic  weapons  systems  developments,  properly 
and  formally  constructed  and  recorded  to  a level  of  indenture  to  allow 
individual  task  identification  and  function  action-information  requirements. 
More  specifically,  mission  phases  and  functions  for  aircraft  operation 
are  sufficiently  common  to  allow  extensive  carry-over  from  one  weapon 
system  development  to  another.  Individual  subsystem  implementation  modes 
and  components  will  have  variations  (e.g.,  single  engine-multi  engine) 
but  the  same  function  will  be  performed  and  must  be  satisfied  in  each 
phase  of  operation,  e.g.,  Pre-Flight,  Taxi,  Take-off,  Climb,  Cruise,  etc. 

The  deviations  may  be  readily  identified  by  the  human  factors  analyst  and 
specific  requirements  and  provisions  for  task  activities  adj us  ted  accordingly . 

However,  the  scope  of  information,  areas  of  concern  and  interactive  elements 
are  such  that  methodology,  in  addition  to  being  applicable  to  the  question 
at  hand,  must  be  manageable  in  both  time  and  manpower  requirements.  The 
techniques  outlined  by  the  methodology  must  be  geared  to  providing  pragmatic 
solutions  to  the  problem  at  hand,  based  on  the  information  available  at  the 
present  time.  Applications  must  also  be  capable  of  utilizing  existing  data. 
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(Continued) 


be  capable  of  -updating  as  new  information  becomes  available,  and  be  available 
to  all  interested  in  utilizing  this  information.  The  solutions  offered  must 
also  be  capable  of  being  modified  and  improved  as  new  or  additional  informa- 
tion becomes  available. 

Developing  a data  storage  system  based  on  such  a philosophy  and  using  a 
functional  flow  concept  to  develop  a range  of  similar  baselines  for  generic 
weapons  systems  developments  (e.g.,  aircraft,  ships,  command-control-communications 
systems)  will  enhance  the  capabilities  of  the  human  factors  engineer  to  rapidly 
and  effectively  establish  design  information  for  a future  development  of  new 
systems.  The  groundwork  for  establishing  most  of  the  preliminary  information 
required  for  workload  analyses  and  function  allocation,  as  well  as  selection 
of  the  equipment  with  which  the  man  interfaces,  can  be  built  up  over  a period 
of  time—  the  information  developed  on  one  weapons  system  can  be  stored  for 
recall,  sorting  and  use  during  development  of  subsequent  systems,  or  for  use 
as  applicable  to  other  types  of  systems.  This  stored  record,  tempered  by  the 
judgment  and  experience  of  the  human  factors  analyst,  can  provide  many  timely 
answers  to  systems  designers.  Thereby , tiai  original  designs  and  configurations 
may  incorporate  desirable  human  factors  refinements  before  system  concepts 
or  physical  structure  become  fixed. 
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2.1.2  General  Human  Factors  Engineering  (HFE)  Responsibilities 

and  Requirements 

During  initiation  of  a typical  system  development  program,  the  HFE  specialist 
is  tasked  to  help  translate  a set  of  general  operational  requirements  into 
specific  concepts  and  requirements  for  system  development.  His  role  is  to 
assure  that  human  performance  and  support  requirements  are  identified  and 
properly  provided  for,  at  any  level  of  system  control,  operation  and  mainte- 
nance. Additionally,  he  must  identify  and  help  resolve  any  significant 
technological  questions  or  data  gaps  that  will  impact  the  development 
program  and  resulting  mission  effectiveness. 

Accordingly,  the  scope  of  the  HFE  role  ranges  from  early  concept  definition 
and  trade-offs  (to  avoid  undue  assumptions  concerning  subtle  human  factors 
elements)  through  detail  design  and  development.  Throughout  a program, 
the  specialist  must  ensure  that  candidate  human  performances  and  support 
requirements  with  corresponding  capabilities  and  limitations  are  properly 
identified,  traded-off  and  implemented.  General  objectives  are  to 
appropriately  provide  for  the  most  effective  contribution  of  human  perfor- 
mance to  mission  success,  and  to  avoid  undue  mission  limitations  or  con- 
straints from  the  human  element  in  the  system. 

In  application,  ability  to  perform  all  the  HFE  tasks  most  effectively  has 
been  limited.  Each  new  system  features  a distinct  set  of  parameters  that 
can  significantly  impact  human  performance  and  support  requirements. 

Effective  performance  of  the  tasks  requires  a comprehensive  knowledge  and 
integration  of  system  mission  and  functional  requirements,  with  control- 
display  state-of-art  and  related  human  performance  capabilities,  limitations 
and  constraints.  While  many  parameters  will  be  familiar  and  routine, 
alternative  applications  can  significantly  change  the  operator  framework 
and  new  applications  concepts  can  pose  totally  new  problems.  While  major 
areas  of  concern  can  typically  be  identified  rather  readily,  the  detailed 
analysis  and  integration  of  all  parameters  to  cover  subtle  variations  with 
significant  effects  is  cumbersome,  time  consuming  and  tedious.  The  level 
of  detail  that  may  be  required  (particularly  for  routine  and  familiar 
concepts)  is  objectionable  to  most  analysts,  with  a most  frequent  complaint 
being  that  they  are "re-inventing  the  wheel"  in  performing  comprehensive 
analyses. 
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2.1.2  (Cont inued) 

On  the  other  hand,  even  very  early  system  development  needs  may  require 
detailed  information  and  long  range  developmental/operations  forecasting 
by  the  HFE  analyst  in  order  to  avoid  eventual  system  mission  limitations, 
constraints  or  retrofits  because  of  human  factor  limitations.  Timing, 
scope  and  foresight  of  the  HFE  specialist  thus  become  critical  in  this 
process.  Even  in  early  conceptual  phases  of  system  development,  he  must 
complete  a preliminary  effort  that  includes  (1)  appraise  the  mission, 

(2)  determine  the  system  functions,  (3)  assess  the  resulting  crew  functions, 
tasks  and  task  elements,  (4)  trade  whether  most  effective  performance  would 
be  by  man  or  machine,  (5)  identify  crew  task  features  and  associated  crew 
capabilities  and  limitations,  (6)  develop  probable  control-display  require- 
ments, features  and  candidates,  (7)  define  and  perform  individual  capability 
trades  for  controls,  displays,  crew  interface  features,  and  crew  performance, 

(8)  conceive  an  effective  crew  station  layout  concept,  (9)  evaluate  the 
resulting  configuration  for  effective  integrated  performance  of  all  tasks, 
and  (10)  confirm  crew  workload  conditions  and  procedures/training  require- 
ments. As  is  readily  obvious,  the  HFE  time  required  can  become  extensive, 
the  process  is  iterative  throughout  system  development,  and  continuing  review 
is  required  to  reappraise  preceding  decisions  in  context  with  developing 
hardware  features.  Concurrently,  more  detailed  levels  of  system  definition 
emerge  and  associated  HFE  studies  progress  with  corresponding  increments  in 
levels  of  detail. 

In  performing  the  HFE  role,  three  sets  of  requirements  apply.  One  is  the 
necessary  information  to  be  developed  for  the  Defense  Systems  Acquisition 
Review  Council  (DSARC)  and  the  four  phases  involved  (Table  2.1-1).  Second 
is  the  detail  requirements  for  HFE  efforts  as  outlined  in  MIL-H-46855 
(abstracted  in  Table  2.1-2).  Third  is  the  scope  of  operator  performance 
variables,  capabilities,  limitations  and  constraints  to  be  considered  in 
trade-offs  by  the  HFE  (a  top  level  summary  is  presented  in  Table  2.1-3;  detailed 
considerations,  constraints  and  data  ramifications  expand  dramatically  from 
this  level). 
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TABI.F  2.1-1 

SUMMARY  OK  HUMAN  FA(  rOKS  KM. I NltF  I Mi  :<HHI  IRKMJ  \ 1 S AND 
R.ISI'ONSibll  f TIES  IN  \ DFVIMH'MKNl  PKOCKAM 


Dt  vc  lopuu  nt 


Phase 

Human  Eng 1 nrer lug  Responsibilities 

I nput  Rt-qn  1 i ciu-at  a 

m-D^ARC* 

Genera l 

1)  Identify  potential  HF 

1)  Cross  op.  requirements 

Opera t ion  1 1 
Require  aeni 

2)  Develop  gross  perf ormanee  criteria 

2)  Technology  forecasts 

2) 

(COR) 

J)  Assess  relevant  HF  data  ava 1 1 abl 1 1 t y 

3)  Alternare  dc3./op 

Tencat i ve 

l)  Analyze  critical  HF  problems 

1)  Outputs  from  COK  phase 

1) 

Specif ic 
Opera r tonal 
Requ  i rement 

2)  Analyze  mission  funct lons/tasks 

2)  System  lime/cost 

2) 

3)  Preliminary  man/machine  (M/M) 

constraints 

3) 

(TSOR) 

al  Locat  ion 

3)  Alternate  dcs./op 

4) 

4)  Estimate  system  HF  efforts 

concepts 

5)  Identify  critical  interface  problems 

6)  Develop  initial  approaches  for 

4)  Empirical  performance 
data 

5> 

alternate  concepts 

Proposed 

1)  Develop  detailed  mission  scenario 

1)  Outputs  from  TSOR  phase 

1) 

Technical 

Approaches 

2)  Perform  m/m  tradeoff  studies 

2)  Hardware/software/op. 

2) 

(PTA) 

3)  Perform  preliminary  operability 

3)  Mission  requirements 

malnta in/ana lysis 

4)  Select  design  charac- 

3) 

4)  Develop  design  optimization 

teristics 

5)  Define  explicit  operating  concept 

5)  Empirical  performance 

4) 

6)  Select  technical  approach  and  develop 

data 

HF  test  plan 

Spec  if ic 

1)  Prepare  detail  HE  test  plan 

1)  Outputs  from  PTA 

1) 

Operational 

Requirement 

(SOR) 

2)  UpJate  previous  HE  analysis 

3)  Develop  operator  station 

2)  Subsystem  interface 
requirements 

2) 

or 

4)  Conduct  trades  and  prepare  specs 

3)  Design  optimization 
trades 

3) 

Advanced 

Development 

5)  Perform  operability  and  maintainability 
analysis 

4)  Cost /schedule  estimates 

4) 

Object lve 
(ADO) 

5)  Empirical  data 

Technical 

l)  Define  m/m  allocation  criteria  and 

1)  Outputs  from  SOR  or 

1) 

Development 

revise  allocation  and  info  flows 

ADO 

Plan 

(TDP) 

2)  Develop  operational  sequencing  diagrams 

2)  Revised  requirements. 

2) 

3)  Refine  HE  data  and  define  HE  technical 
program 

design  concepts  and 
m/m  allocation 

4)  Develop  RFP  work  statements,  system  specs 
and  proposal  evaluation  criteria 

3)  Results  of  trade 
studies  and  system 
tests 

3) 

4) 

4)  Empirical  data 

DSARC  I 

Request  for 

1)  Analyze  problem  areas  identified  in  RFP 

1)  Outputs  from  TDP 

1) 

Proposal 

(RFP) 

Preparation 

2)  Integrate  HF  contributions  to  prel. 

2)  Specific  hardware 

design  of  baseline  configuration 

requirements  and  costs 

3)  Update  all  HE  outputs  and  empirical  data 

3)  Human  perf.  require- 

4) Expand  functional  analysis  and  alloca- 

ments 

tion  to  final  level 

4)  Updated  design, 

5)  Finalize  RFP  statement  of  work 

layout  and  plans 

5)  Empirical  data 
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Output  P 


Potential  1IF  problem 

do  f Ini t ion 

Pit f orm.iuce/operat  I 

criteria 


Cross  mission  scenat lo 
Function  flow  chart 
M/M  task  allocation 

Man/maciiine  Interface 
def lull ion 

Recommended  technical 
approaches 


Performance  goals/ 
requirements 

Operator /maintenance 
skill  requirements 

HF  concepts  and  data 
for  PTA  preparation 

Tech,  approach  and 

test  plan 

Operability  and  maintain- 
abi 1 ity  goals 

Detailed  HE  plans 

Expanded  station 
design  concept 

HE  system  specs 


Revised  data  and 
concepts 

Initial  RFP  work 
statement,  system 
spec,  etc. 

Major  problem  area 

HE  technical  program 
plan  description 


Finalized  RFP  SOW  to 
be  issued  to  contract 


tabik  2.1-1  (Continued) 


Development 

Phase 


Proposi  l 
Ev.ilu.it  Ion 


DSARC  XI 

Prototype 
Development , 
Eva  ludt ion 
and  First 
FI  lght 


Deployment 
Fva luat Jon 


DSARC  in 
Prod tic  t Ion 


Human  Engineer  Jug  Responsibilities  Input  Requirements 

1)  Evaluate  contractor  proposals  In  terms  Sunn  as  above  plus  output* 

of  adequacy  of:  from  KKF 

a)  liulerHtan.il  the  role  of  HE 

relative  to  overall  system 

b)  Soundness  of  approach 

c)  Design  tradeoff  pyrometers 

d)  Proposed  solutions  to  special 
HE  problems 

e)  Mockup,  development  and  utilization 

f)  Test  and  evaluation  plans  and 
methodologies 

2)  Identify  critical  areas  not  noted  by 
contractors 


1)  Participate  In  detail  designs  for  air-  Varying  according  to 

craft  and  subsystems  and  support  and  types  of  component 

training  equipment  models  used 

2)  Perform  tests  to  verify  man/machine 
performance/ procedures 

3)  Monitor  detail  engineering  changes  and 
note  problems 

4)  Develop  plans  and  procedures  for 
training 

5)  Evaluate  and  review  progress  reports 

6)  Inspect  and  evaluate  prototype 

7)  Identify  special  problems  and  coordi- 
nate with  contractor  for  optimum 
solutions 

8)  Conduct  laboratory,  ground  simulation 
and  flight  tests  to  evaluate  HE  per- 
formance (e.g.,  time  and  motion,  work 
load,  job  aids,  m/m  interface) 

9)  Participate  in  development  of  detail 
plans  for  first  flight 

10)  Redefine  operability  and  maintain- 
ability goals 

11)  Test  and  evaluate  maintenance  and 
training  equipment  and  procedures 

12)  Develop  rer o.rjncndat  ions  .f or  improved 
system  design  and  operational  procedures 


1)  Identify  and  evaluate  operational  Vary  according  to  types 

deficiencies  of  component  models 

2)  Propose  new  technology  feasibilities  used 

3)  Update  data  bank  and  replace  previous 
estimates  with  operational  data 

4)  Re 'lse  technical  training  and 
maintenance  manuals 


1)  Ensure  production  unit  comply  with  Same  as  above 

contract 


Out  I it  a 

Written  reports  ol  each 

task 


1)  Mockup  demonst i at  ion 

data 

2)  HE  design  specifi- 
cation document 

3)  Detailed  design  layout 
or  work  station  and 
equipment  performance 
specif lcations 

4)  Detail  plans  for  flight 
test,  training  and 
operation 

5)  Specific  recommenda- 
tions for  design  and 
procedure  improvements 

6)  Updated  HE  technical 
manuals 

7)  Training  and  maintenance 

manuals 


1)  Finalized  operational, 
design,  training  anil 
maintenance  documents 
and  manuals 

2)  Updated  11E  technical 
program  specifica- 
tions and  operational 

data 


Written  reports  of  each 

task 


table  2,1-2 

Oil'll.  INF  OF  MIL-H-4bH5b 


\ 


f 


> 


X 


h 

I 

i 


3.1  General  K>  oulrvM  ius 

3.1.1  Scope  .’.'aluri1  ol  Work 
o Analysis 

o Deslgn/Devtlopmenc 
o Test  and  Evalu.it Ion 

3.1.2  Human  Engineering  Program  Flan  and  Other  Dai  a 

3. 1.2.1  Human  Engineer  ing  l'rogr  ini  Plan 

3. 1.2-2  Changes  to  the  Human  Engineering  Program  Plan 
3. 1.2.3  Other  Data 

3.1.3  Nc n Duplication  (of  Effort) 

3.2  Detail  Requirements 
3.2.1  Analysis 

3.2.1. 1 Defining  and  Allocating  System  Functions 

3.2. 1.1. 1 Information  Flow  and  Processing  Analysis 

3. 2. 1.1. 2 Estimates  of  Potential  Operati  r/Malntainer  Processing  Capabilities 

3. 2. 1.1. 3 Allocation  of  Functions 

3.2. 1.2  Equipment  Identification 

3.2. 1.3  Analysis  of  Tasks 

3. 2.1. 3.. 1 Gross  Analysis  of  T.isks,  Involving/Providing 

1.  Determine  System  Performance  Can  Be  Provided  by  Proposed  Personnel-Equipment  Capabilities 

2.  Assure  Human  Performance  Requirements  Do  Not  Exceed  Human  Capabilities 

3.  Input  Data  for 

o Preliminary  Manning  Levels 
o Equipment  Procedures 
o Skill/Truining  Requirements 
o Communication  Requirements 

4.  Critical  Human  Per f ormar.ee 

5.  Possible  Unsafe  Practices 

6.  Promising  Improvements  in  Operating  Efficiency 

3. 2. 1.3. 2 Analysis  of  Critical  Tasks 

1.  Identifying 

o Information  Required  by  Man,  Including  Task  Initiation  Cues 
o Information  Available  to  Man 
o Evaluation  Process 
o Decision  Reached  After  Evaluation 
o Action  Taken 

o Body  Movements  Required  by  Action 
o Workspace  Envelope  Required  by  Action 
o Workspace  Available 

o Locat ion/Cond It  Ion  of  Work  Environment 
o Frequency/Tolerances  for  Action 
o Time  Base 

o Feedback  on  Action  Adequacy 
o Tools  and  Equipment  Required 

o Number  of  Personnel  Required  and  Special t Ics/Experlencc 
o Job  Aids/Kef erent os  Required 
o Special  Hazards  Involved 

o Operation  Interaction  Where  More  Than  One  Crewman  Is  Involved 
o Operational  Limits  of  Man  (Performance) 
o Opi  r.itlon.il  Limits  of  Machine  (Srot*  -of-thc-Ar t ) 

2.  Covering  All  Affected  Miss  Ion/ Phases , Including  Degraded  Modes  of  Operation 

3.2. 1.3. 3 Loading  An  i lysis 

1.  Individual  Crew  Member  Workload  Analysis  Compared  with  Performance  Criteria 

2.  Crew  Workload  Analysis  .mpond  With  Perl orm.in.-e  (rfrnri.-i 

3. 2. 1.4  Pt el imlnnry  System  and  Subsystem  Design 
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3.  2. 2.1.1  Hoi  Mijis  and  Model:* 

3.2.2.  1.2  Dynamic  S lmul.it  Ion 

3. 2. 2. 2  I <|u  Ipmcnr  D«  t » l J Design  Drawing* 

3.2.2.  i Work  Env  1 1 uu;m-iU  , h rcw  Stations  and  Fad  lit  1«  . Ik-  sign 
o Atmospheric  Conditions 
o Weather  and  Climate 
o Range  of  AcceloraC  1 ve  Forces 
o Acoustic  No  so , Vibration  and  Impact  Forces 
o Provision  fsir  Human  Performance  During  Weightlessness 
o Provision  for  Minimizing  Disorientation 
o Spa  £ for  Crew,  Activity  and  Equipment 

o Physical,  Visual  jiuJ  Auditory  Links  for  All  Maii'Enu  lpmeut  Interfaces 
o Safe,  Ffficient  Walkways,  Stairways,  Platforms,  Inclines 
o Provision  to  Minimize  Psychophys lological  ‘‘tresses 

o Provision  to  Minimize  Fatigue  Physical,  Emotional,  Work-Rest  Cycle 
o Effects  of  Clothing,  Personal  Equipment 

o Equipment  Handling  Previsions,  including  Remote  Handling  and  Tools 

o Protection  from  Hazards  - Chemical,  Biological,  Toxi eologi .al , Radiological , Electrical 
Electromagnet ic 

o Optimum  Illumination  Per  Visuil  Tasks 
o Sustenance,  Storage  and  Sanitation 

o Crew  Safety  Protection  Relative  to  Mission  Phase  and  Contrc 1-Display  lasks 

3.2. 2.4  Human  Engineering  in  Perf orraance  and  Design  Specifications 

3.2.3  ^uiprient  Procedure  Development 

3.2.4  Hunan  Engineering  Test  and  Evaluation 

3. 2. 4.1  Planning 

3. 2.4. 2 Implementation  ( Include  As  Applicable) 

o Simulation  or  Actual  Conduct  of  Miss ion/Work  Cycle 
o Human  Participation  Critical  to  'Speed,  Accuracy,  Reliability,  Cost 
o Representative  Sample  of  Non  Critical  Seheduiod/Unscheduled  Maintenance  Tasks 
o Proposed  .lob  Aides 

o L’se  of  Rcpresentat  ive  User  Personnel.  Clothing  and  Equipment 
o Task  Performance  Data  Collection 

o Task  Performance  Discrepancies  - Required  vs  Obtained 
o Criteria  for  \cceptablo  Per lormance 

3. 2.4. 3 failure  Analysis  (Human  Error  Factors) 

3.2.5  Cognizance  and  Coor J mat  ion  (interdisciplinary  integration) 

3-3  Data  Requirements  Per  Contract  Data  List 

3.4  Data  Availability  to  Procuring  Activity 

3.5  Drawing  Approval  by  HFf.  for  Man-Machine  Interfaces 
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TABLE  2.1-3:  REPRESENTATIVE  OPERATOR  PERFORMANCE  VARIABLES 
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Ambiguity  in  Data 
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Problem  Complexity 
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Display  Emphasis 
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Other 

Control  Operation  Factors 
(Manual/Motor  Capability 
and  Skills) 


Accesv/Cont  rol 

Le  it  ion 

Correlated  Displays 

Reliability 

Functional  Reqi 
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Correlated  Actions 
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‘•rouping 
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Logic  Diagrams 
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Discrete/Cont inuous/ 

Cod  in;:  (Des  ign.it  ion  ’ i / 

1 nt  ermi ttent 

Act  ions 

Shade) 

Work  Space  Envelope 

(Stat ion  Layout /Human  Anthro- 
pomer rv/Mobi 1 itv  Required) 


Environmental 

(General  Impact  an  Performance/ 
Physiology) 


General 
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Grouping  (Posit ior  Corre- 
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-Access/Roach 
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Priorities 
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Tradit ion/Arr opt anc 


2.1.2 


(Cont  i mii'd ) 


i 


1 \ 

i 

1 3 

! t 

i 


In  prai t ice,  achieving  all  HFK  requirement  and  objectives  has  been  a massive 
and  complex  job.  There  lias  been  no  generally  accepted  and  applied  standardized 
approach,  nor  has  there  been  any  precise  and  systematic  definition  of  the 
processes  involved.  HFE  approaches  have  been  highly  individualized  and 
heavily  dependent  on  professional  experience,  skill  and  judgment.  Initially 
individuals  used  the  approach  that  best  suited  their  own  needs  as  required, 
to  define  and  maintain  an  overall  system  concept,  to  identify  and  track 
relatively  routine  areas  of  development,  and  to  identify  and  resolve  unique 
or  critical  problem  areas.  Unfortunately,  the  record  demonstrates  that 
many  areas  were  overlooked.  Use  of  the  more  intuit  t ve,  ind ividua 1 i zed 
approach  became  even  less  satisfactory  with  the  advent  of  increasingly 
complex  systems. 

HFE  system  analysis  techniques  were  developed  to  provide  a more  systematic 
progression  of  methods  that  would  enhance  quality,  impact  and  thoroughness 
of  technical  effort.  Analytic  methods  that  evolved  parallel  the  require- 
ments of  Ml L-H-46855  in  supporting  system  development  from  early  concept 
formulation  through  detailed  analysis  and  critique  of  task  performance 
requirements,  capabilities  and  workload.  However,  applications  of  many 
of  the  methods  are  still  in  the  evolutionary  stage,  and  there  has  been 
inadequate  development  and  correlation  of  information  in  the  sequence  of 
methodological  steps,  so  that  outputs  from  one  step  are  not  yet  clearly 
defined  inputs  for  the  next.  More  systematic  applications  remained 
heavily  a function  of  individual  expertise  and  judgment:  in  skipping  steps, 
in  using  intuition  and  insight,  and  in  "optimizing"  the  risks  accepted  in 
making  short  cuts.  Redundancy  between  systems  still  carried  some  of  the 
notion  of " re-in vent ing  the  wheel"  and  a tendency  to  avoid  some  elements 
as  unnecessary.  Unfortunately  there  remained  a corresponding  risk  of 
overlooking  key  data  elements,  of  ignoring  an  unfamiliar  problem  area, 
or  of  failing  to  perceive  the  implications  of  a new  context  for  traditional 
or  routine  systems  and  equipment  concepts. 

In  summary,  the  basic  approach  sequence  for  HFE  requirements  is  outlined 
in  MIL-H-46855.  However,  applications  have  lacked  in  consistent  utilization 
of  a precisely  defined  and  systematic  procedure.  In  turn,  computer  modeling 
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2.1.2  (Continued) 

has  been  somewhat  constrained  by  the  absence  of  logical,  quantifiable  steps 
in  procedure;  and  submodel  development  has  been  more  general  purpose  than 
desirable  in  concept,  in  order  to  suit  alternative  approaches.  On  the  other 
hand,  if  an  approach  were  adopted,  developed  and  stored  to  offer  information 
rapidly,  and  with  little  or  no  effort  by  the  analyst,  it  would  very  likely 
be  used  extensively. 

The  Computer  Aided  Function-Allocation  Evaluation  System  (CAFES)  is  a 
computerized  design  tool  being  developed  to  assist  the  human  factors 
engineering  analyst  in  system  development  programs.  Basic  features  are 
summarized  in  Table  2.1-4,  reflecting  both  a correlation  with  many  of  the 
requirements  of  M1L-H-46855  and  capabilities  for  resolving  some  of  the  problems 
described  in  earlier  text.  CAFES  is  a crew  systems  design  support  tool 
based  on  human  engineering  methods,  computer  aids,  human  performance  data, 
and  data  management  needs.  It  is  intended  to  support  crew  systems 
engineers  in  system  development  efforts,  including  man-machine  research, 
requirements  analysis,  design,  test,  training,  and  maintenance  systems 
development.  Principle  advantages  are  that: it  can  be  applie  ! extremely 
early  in  concept  development  to  retrieve,  structure  and  use  available 
information,  it  can  continue  to  be  used  as  a developmental  tool  and  as  a 
recording  system  for  on-going  project  efforts,  and  it  can  expedite. 

Considerable  potential  for  CAFES  refinement  to  reduce  system  development 
workload  for  the  analyst  was  considered  to  exist  if  a manual  methodological 
concept  were  to  be  devised  that  could  satisfy  all  the  hardware  system  program, 
specification  and  technological  requirements  indicated  earlier.  By  esta- 
blishing an  appropriate  analytic  baseline  for  both  manual  methods  and  for 
application  of  CAFES  computer  models,  much  of  the  manual  organization  of 
concepts  and  data  could  be  pre-constructed  and  stored  in  the  CAFES  framework. 
Accordingly,  the  analyst  could  avoid  excessive  involvement  in  detailed 
concept  structuring  or  programming  type  operations.  Instead,  he  could  use 
and  manage  the  pre-stored  data  by  exception  or  by  refinement  and  expansion. 
Accordingly,  it  would  be  easier  to  use  the  pre-structured  baseline  as  a 
"spring  off"  for  added  developments,  than  to  become  heavily  involved  in 
organizing  relatively  routine  concepts  and  data. 
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' \ BL  E 2.1-4:  CAFFS  El.  EM  ENTS  APPLIED  TO  WEAPON  SYSTEM  DEVELOPMENj 
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2.1.2 


(Continued) 


The  present  study  was  thus  to  develop  a baseline  approach  for  HFE  analysis 
that  would  support  all  requirements,  provide  an  initial  concept  for  a 
future  system,  and  provide  a reference  model  for  identifying  candidate 
CAFES  refinements.  An  essential  element  was  to  identify  concepts  that 
could  enhance  CAFES  use  and  interpretation,  including  assistance  in 
spotting  problem  areas  in  providing  solutions,  and  evaluating  effectiveness 
of  the  solutions. 

An  important  feature  of  this  approach,  was  to  provide  a framework,  for  the 
retention  and  application  of  essential  and  critical  analyst  capabilities 
as  part  of  the  process,  so  that  he  could  understand  and  use  CAFES  effec- 
tively to: 

o Identify  critical  system  problems. 

o Provide  innovative  solutions  to  non-routine  or  extremely  difficult 
problem  areas. 

o Evaluate  the  implications  of  model  operations  and  data  quality  relative 
to  the  problem  at  hand. 

o Off  load  routine  data  retrieval,  organization  and  calculation  functions. 

basic  CAFES  structure  provides  considerable  assistance  along  such  lines. 

The  intent  of  the  "single  thread  baseline"  concept  was  to  establish  a 
bridge  between  representative  manual  methods  and  operations  on  one  hand 
and  the  CAFES  submodels  on  the  other  hand.  This  was  to  include  definition 
of  more  routine  programmable  and  tedious  elements  in  contrast  to  analyst 
needs  and  capabilities  as  an  evaluator,  decision  maker,  problem  solver 
and  innovator. 
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ANALYTICAL  PROCESS  DEVELOPMENT 


2.  2 

Evolution  of  a baseline  process  methodology  for  HFE  activities  has  been  in 
developmental  stages  for  many  years.  This  is  the  set  of  activities,  and 
the  sequence  of  events,  which  are  undertaken  by  the  human  factors  analyst 
during  a system  development  cycle.  A number  of  approaches  have  been 
developed  as  each  of  the  HFE  activity  elements  has  been  examined,  changed, 
altered,  added  to,  excluded,  given  different  emphasis,  resurrected  under 
different  titles  and  had  format  and  content  altered.  Throughout  this 
evolutionary  process  (which  is  still  going  on)  there  has  been  an  evolution 
of  a more  consistent  set  of  definitions,  a general  agreement  on  the  ordering 
of  the  elements  and  a general  agreement  on  the  definition  of  the  elements. 

Production  of  a baseline  human  factors  engineering  methodology  with 
intended  use  of  the  CAFES  submodels  as  an  integral  part  is  a unique  tinder- 
taking. The  processes  and  techniques  involved  in  CAFES  are  not  new  but 
in  the  past  have  required  manual  efforts  of  such  duration  as  to  frequently 
render  the  results  more  of  a verification  of  previous  decisions  than  a 
design  tool  to  be  used  during  the  development  of  the  weapons  system.  The 
use  of  computer  computational  speed  and  capacity  to  support  the  process  in 
CAFES  provides  for  quick,  accurate  data  retrieval,  organization  and  calcu- 
lations, and  also  the  storage  and  processing  capacity  necessary  for  a 
newer  analytic  mode  — to  begin  comparison  to  alternate  solutions  within 
an  early  time  frame  compatible  with  the  weapons  system  development  needs. 
Producing  initial  weapon  system  mission  functional  flow  definitions  will 
still  be  laborious  and  time  consuming,  but  because  of  redundancy  and 
commonality  between  systems  (e.g.,  between  aircraft)  can  be  used  indef- 
initely. It  is  only  necessary  that  new  system  elements  or  unique  mission 
related  functional  requirements  will  require  definition  for  a new  applica- 
tion of  a weapon  system.  Analysis  and  comparison  of  alternate  functions 
allocations  and  refinements  anywhere  in  the  analytic  structure  will  be 
readily  and  quickly  accomplished  in  CAFES,  and  presentation  methods  are 
available  for  the  analyst  to  comprehend  and  interpret  data,  implications 
and  results. 
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(Continued) 


Development  of  a baseline  process  has  required  re-examination  of  candidate 
HFE  activity  elements  related  methodological  concepts  and  their  relation- 
ship with  Computer  Aided  Function-Allocation  Evaluation  Systems  (CAFES) 
submodels.  The  submodels  are  designed  to  do  the  routine  data  retrieval, 
organization  and  calculations  necessary  to  support  the  analytic  process, 
by  acquiring  and  helping  to  apply  useful,  comprehensive,  comparative  and 
absolute  data.  These  data  processes  and  calculations  are  needed  from 
early  functions  allocations  through  detailed  evaluation  of  physical  and 
visual  compatibilities  of  crew  and  crew  station  configurations,  task 
sequencing,  detailed  task  allocation  between  man  and  machine,  task  alloca- 
tion among  crew  members,  crew  workloads  and  effectiveness  of  a given  task 
set  vs  mission  requirements. 


2.2.1 


Baseline  Process 


More  general  bui  typical  areas  of  HFE  activity  during  a system  development 
cycle  are  illustrated  in  Figure  2.2-1.  This  figure  provides  a summary  of 
the  types  of  efforts  and  expected  inputs.  A summary  concept  for  the 
overall  flow  of  HFE  task  processes  is  shown  in  Figure  2.2-2.  This  figure 
summarizes  the  internal  working  relationship  for  HFE  tasks  and  illustrates 
directly  or  by  implication  the  i nterelationship  of  these  tasks  with  hard- 
ware, software,  manning,  training  and  procedures  activities. 

The  specific  Baseline  Process  "single  thread"  Methodology  sequence  adopted 
for  purpose  of  the  present  study  is  diagrammed  in  Figure  2.2-3.  The 
approach  outlined  identifies  both  specific  HFE  efforts  and  their  sequencing, 
for  a system  development  program  carried  out  from  early  concept  formulation 
on  through  Ihe  design  and  development  process.  Subsequent  discussion  in 
this  section,  on  Analytic  Process  Development  expands  on  the  approach  by 
providing  summary  descriptions,  by  outlining  any  particular  restraints 
or  ground  rules  for  application,  and  by  providing  examples  as  appropriate. 
This  approach  provides  for  developing  the  information  that  was  required 
by  the  system  acquisition  requirements  that  were  summarized  in  Table 
2.1-1.  It  is  structured  in  such  a way  that  the  analyst  can  adopt  and 
follow  the  methodology  usefully,  early  in  a program,  can  retrieve  and 
organize  such  information  as  exists  and  is  recorded  in  a meaningful, 
useable  format,  and  can  initiate  an  analytic  process  that  can  be  used 
through  system  development. 

2, 2. 1.1  Operational  Requirements/Mission  Profile 

The  general  system  operational  requirements  are  an  evolving  composite  of 
requirements  starting  with  the  General  Operational  Requirement  (GOR)  and 
progressing  through  the  Specific  Operational  Requirements  (SOR)  as  was 
illustrated  in  Table  2.2-1.  The  operational  requirements  define  the 
system  for  developmental  consideration  and  outline  the  limits  of  operations 
necessary  for  the  fulfilling  of  the  weapons  system  mission  activities. 

During  the  progressive  evolution  of  the  system,  iterative  updates  and 
expansions  are  incorporated  from  various  analysis,  evaluation,  production 
and  user  groups.  A detailed  and  complete  definition  of  system  operational 


25 


Crew  size  Definition  [ Typical  HFE  Activities 


Performance /Operational  Criteria  Definition 


HL  Problem  Identification/Definition 


Data  Retrieval  and  Update 


Man-Machine  Function  Allocation 


Man-Machine  Interface  Analysis 


Cost- Effectiveness  Trades  - Approach  Definition 


Test.  Demonstration  and  Evaluation 


System  Specs  Development 


Preliminary  Desi«„  and  Livoul 


Detailed  Systems  Design 


Lv-sirsl 


Planning,  Adv  Development 


6 Contract  Award 


FIGURE  2.2-1  : 
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FIGURE  2.2-2:  SUMMARY  IIFE  TASK  FLOW 
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requirements  provide  the  judgemental  criteria  hv  wliicli  elements  of  the 
weapons  system  may  he  compared  and  evaluated  for  mission  suscces 
probab i 1 i t i es . 

Even  initial  general  requirements  will  include  such  features  as  the 
types  of  activities  to  he  performed,  the  duration  of  each  activity 
requirt'd,  physical  character ist ii s necessary  to  satisfy  system  functions 
to  b,  performed,  and  perhaps  the  desirabie  crew  complement  to  perform 
the  necessary  functions.  Initial  Hl’E  task  activity  will  include  identi- 
fication of  any  human  factors  problem  areas  and  general  performance- 
operating  considerations,  requirements  and  crtieria.  As  the  concept 
definition  evolves,  such  activity  will  become  similarly  more  definitive. 

During  early  definition  of  operational  requirements  and  associated  opera- 
tional descriptions,  an  initial  mission  profile  (such  as  is  illustrated 
for  aircraft  in  Figure  2.2-4)  can  be  constructed  to  graphically  depict 
major  requirements  in  the  form  functional  elements  in  the  profile.  Each 
functional  element  (or  functional  requirement)  describes  a segment  of  the 
mission.  Each  segment  is  self-contained,  that  is,  it  has  a clearly 
distinguishable  start-to-complete  operation,  setting  the  stage  for 
subsequent  indentured  breakdown  for  more  detailed  functional  requirements. 

2.2. 1.2  Mission  Scenario/Gross  Timeline 

Mission  Scenario 

The  Mission  Scenario  is  developed  from  the  mission  profiel  and  operational 
requirements.  In  narrative  form,  the  Mission  Scenario  verbally  describes 
the  events  which  make  up  tiie  full  mission  or  segments  of  the  mission, 
summarizing  typical  operations,  assumptions,  mission  environment  and 
mission  events  that  might  occur.  Key  events  in  normal  and  degraded 
operations  are  identified  and  explained  in  an  operational  context  to 
ensure  that  all  requirements  can  be  identified  and  are  examined  during 
the  course  oi  the  evaluation.  The  scenario  provides  the  source  of  infor- 
mation needed  to  confirm  understanding  oi  desired  system  operations, 
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to  detail  system  functions,  action  and  information  requirements,  and  to 
develop  a detailed  functional  flow. 

Tiie  scenario  is  one  of  the  many  critical  segments  in  the  early  definition 
of  weapons  systems  requirements.  Because  the  scenario  reflects  integra- 
tion of  operational  requirements,  it  is  the  initial  source  of  information 
to  establish  such  system  elements  and  constraints  as  are  related  to  crew 
size,  crew  functions,  and  equipment  candidates.  All  decisions  throughout 
development  will  ultimately  refer  back  to  the  initial  requirements 
definition  and  scenario  to  resolve  any  conflicts  of  judgement  or  equipment 
selection  and  use. 

Klements  of  the  scenario  must,  at  a minimum,  be  sufficiently  detailed 
to  convey  a comprehensive  understanding  of  the  mission,  and  to  permit  . 
break  out  of  variations  relating  to  such  features  as  (1)  the  phases  of 
the  mission,  (2)  the  type  of  activity  performed  in  each  phase,  (3)  the 
degree  of  accuracy,  (41  any  interdependencies  of  activities  as  to  timing, 
information  transfer,  etc.,  and  (5)  the  functions  allocated  to  specific 
types  of  hardware, to  a crewman  or  to  a combination  of  tie  man  and  a 
-ibsystem. 

Scenario  narrative  usually  is  capable  of  providing  the  above  information. 
The  narrative  form  often  provides  more  information  that  is  necessary  for 
.subsequent  analytic  steps,  but  it  does  assist  in  establishing  an  implied 
boundary  to  the  scope  of  mission  concept  and  operations  which  may  or  nay 
not  be  established  by  the  operating  requirements  or  design  specifications. 
The  provision  of  a narrative  scenario  also  provides  an  early  opportunity 
for  re-evaluation  of  mission  concepts  and  definitions  to  ensure  system 
mission,  objectives  and  requirements  are  clearly  defined  and  described. 

The  following  example  of  a narrative  scenario  (modified  from  reference  43) 
is  included  in  this  section  to  provide  both  an  illustrative  example  and 
a basis  for  examining  the  Functional  Flow  Block  Diagrams  which  may  be 
generated  from  the  scenario.  As  will  be  evident,  it  would  take  very  little 
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additional  information  to  incorporate  and  fully  describe  detailed  criteria 
and  capabilities  of  all  systems,  including  operating  constraints  and  key 
failure  modes. 


Scenario  Example:  VFA-V/STOL  Aircraft,  Close  Air  Support 

Sea  Control  Ship  - 81  (SCS-81)  is  on  station  160  miles  Southwest  of  the 
battle  area.  At  a pre-dawn  briefing  VFA-V/STOL  squadron  pilots  are 
informed  that  major  ground  offensives  are  to  be  initiated  at  daybreak, 
it  is  anticipated  that  Close  Air  Support  (CAS)  will  be  required  and  two 
of  SCS-81's  VFA-V/STOL's  have  been  configured  for  this  mission;  anti- 
personnel and  armor  piercing  munitions  have  been  loaded,  the  modular  CAS 
peculiar  avionics  have  been  installed,  and  all  auxiliary  CAS  software  has 
been  loaded.  Routine  briefing  information  is  exchanged-inc Lud ing  weather, 
anticipated  defenses,  modes  and  codes  of  the  day,  departure  and  battle 
area  communication  frequencies,  and  launch  times.  The  two-man  flight 
has  been  designated  Yankee  Flight.  Detailed  pre-flight  inspections  had 
been  completed  earlier  and  the  pilots  quickly  move  to  their  aircraft 
and  start  engines.  System  checks  are  run  while  that  equipment  requiring 
initialization  is  brought  on  line.  The  first  VFA-V/STOL  is  spotted, 
launch  clearance  is  obtained  and  a short  takeoff  (STO)  is  executed. 

Figure  2.2-5  depicts  the  mission  graphically  and  Table  2.1—5  contains 
the  mission  segments,  or  phases. 

Yankee  Leaker  takes  off,  retracts  gear  and  flaps  and  begins  transition 
to  completely  conventional  flight.  A quick  glance  at  his  emergency/warning 
multi-purpose  display  re-assures  him  that  all  systems  are  functioning 
properly.  He  begins  a climbing  turn  to  the  selected  inland  heading  and 
visually  spotting  his  wingman  begins  accelerating  to  maximum  endurance 
airspeed  and  altitude.  He  notes  on  his  horizontal  situation  display  the 
electronically  generated  way  points  and  check  points  superimposed  over 
ti  ■ projected  map  presentation.  Switching  UHF  frequencies,  Yankee  Leader 
contacts  the  Direct  Air  Support  Center  for  his  specific  assignment  and 
enroute  clearance.  He  and  his  wingman  are  assigned  to  Airborne  Forward 
Air  Controller-Alpha  (FAC (A)-Alpha)  and  are  given  a vector  to  Alpha  from 
their  coast  checkpoint.  The  outbound  cruise  is  routine.  The  passive 
threat  detection  and  warning  system  is  very  quiet;  the  radar  is  placed 
in  standby,  and  the  prominent  coastal  checkpoint  will  be  acquired  either 
visually  or  electro-optically. 

At  dawn  the  ground  feature  check  point  is  detected  and  confirmed  by  sensors 
at  an  extended  range.  Yankee  Leader  raises  Forward  Air  Controller-Alpha 
FAC(A)-Alpha  on  the  pre-assigned  secure  communication  channel  and  receives 
his  specific  mission  assignment  and  a more  complete  briefing,  FAC(A) 
informs  Yankee  Flight  that  an  advance  enemy  force  has  moved  up  during 
the  night  and  will  soon  be  within  striking  distance  of  a strategic 
friendly  position.  The  enemy  force  consists  of  many  troops,  light  armored 
vehicles,  and  rocket  launchers.  Recent  experience  has  indicated  that  the 
enemy  will  also  be  equipped  with  advanced  capability  portable  infrared 


TABLE  2.1-5  CLOSE  AIR  SUPPORT  - FUNCTIONAL  MISSION  PHASES 
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Scenario  (Continued) 

homing  missiles.  There  is  no  enemy  air  support.  Preparations  are  under- 
way for  defense  against  the  imminent  attack.  FAC(A)-Alpha  provides  an 
updated  vector  from  the  coastal  checkpoint  and  assigns  Yankee  Flight  a 
loiter  position.  Yankee  Leader  provides  an  estimated  time  of  arrival 
(ETA)  and  crossing  the  coastline  performs  a navigation  update,  reduces 
power,  and  drops  to  a terrain  following  altitude.  The  penetration  route 
has  been  chosen  to  minimize  detection.  No  known  enemy  radar  sites  are 
along  the  route.  There  are  no  rockets  indicated  by  the  threat  detection 
and  warning  set.  Anticipating  his  upcoming  strikes,  Yankee  Leaker  reviews 
his  ordnance  load. 

Reaching  the  loiter  point,  Yankee  Flight  re-establishes  contact  with 
FAC(A)-Alpha  for  update  and  target  information.  Alpha  reports  that 
friendly  troops  are  presently  pinned  down  under  enemy  rocket  and  mortar 
shelling.  Strikes  against  enemy  artillery  could  force  it  to  seek  cover 
which  would  allow  friendly  ground  troops  to  move  up.  FAC(A)-Alpha  and 
Yankee  Flight  establish  visual  contact  and  the  FAC(A)  reports  that  he 
will  transmit  coordinates  of  the  enemy  position.  Since  the  weather  is 
excellent  and  the  attack  will  be  executed  visually,  Yankee  Leader  selects 
a tactical  presentation  and  selects  the  air-to-ground  mode  on  his  elec- 
tronic displays.  Also,  since  the  enemy  is  still  removed  from  the  friendly 
forces,  Yankee  Leader  decides  on  a low-level  approach,  pop-up,  and  rocket 
attack.  In  order  to  take  maximum  advantage  of  a possible  suprise  element, 
Yankee  Red  will  Execute  the  same  attack  from  a different  heading.  Yankee 
Leader  designates  the  reference  coordinates  on  his  tactical  display  for 
steering  commands;  due  to  the  relatively  flat  terrain  he  selects  a narrow 
field  of  view  (NFOV)  for  the  display  on  the  Vertical  Situation  Display 
(VSD).  Verifying  and  arming  his  ordnance  selection,  he  coordinates  with 
Yankee  Red  and  initiates  his  low-level,  high  speed  dash.  Maintaining  a 
precise  heading,  Yankee  Leader  detects  his  target  several  miles  out  and 
makes  minor  steering  corrections.  He  pops-up,  enters  the  dive,  tracks 
his  targets  and  launches  his  ordnance.  FAC(A)-Alpha  confirms  that  his 
attack  has  eliminated  two  of  the  enemy  rocket  launchers.  Yankee  Red  has 
equal  success  a few  seconds  later.  Circling  high  above  the  battle  area, 
FAC(A)-Alpha  reports  that  the  remaining  rocket  launchers  are  moving  to 
what  little  cover  there  is,  while  ground  troops  and  many  small  vehicles 
are  advancing. 

Yankee  Leader  and  FAC (A)-Alpha , in  conjunction  with  the  FAC(G)  (Forward 
Air  Controller-Ground),  decide  upon  additional,  low  level  strikes  utilizing 
the  aircraft  cannon.  Yankee  Leader's  break-off  has  removed  him  from  the 
immediate  battle  area  but  the  coordinates  for  the  rocket  attack  were 
precise  and  he  can  accurately  and  quickly  return  to  the  battle  area.  He 
selects  the  guns  to  be  employed.  With  the  element  of  suprise  gone,  Yankee 
Leader  is  primarily  concerned  with  encountering  the  infrared  missiles. 

After  coordinating  with  FAC(A)-Alpha  and  Yankee  Red,  Yankee  Leader 
initiates  his  return  to  the  battle.  Slewing  the  high  resolution  sensor 
to  designated  reference  points  on  his  tactical  display,  Yankee  Leader 
can  begin  a preliminary  search  of  the  target  area  before  visually  acquiring 
it.  Assuming  that  any  mobile  missiles  are  confined  to  the  immediate  battle 
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Scenario  (Continued) 

area, Yankee  Leader  climbs  to  a better  search  altitude  and  reduces  airspeed 
somewhat.  He  monitors  his  threat  detection  and  warning  information  care- 
fully. While  slewing  the  sensor  the  pilot  detects  some  small  vehicular 
traffic.  Yankee  Leader  increases  power  and  heads  directly  along  the 
bearing  to  these  targets.  Still  searching  with  his  sensor,  he  notes  what 
appears  to  be  troop  activity  and  makes  the  necessary  steering  adjustments. 
Not  completely  sure  of  the  activity  he  has  detected  he  requests  (FAC(G) 
to  mark  the  forward  edge  of  the  friendly  position.  Sweeping  the  appropriate 
sensor  in  the  direction  he  believes  to  be  toward  the  friendly  forces  he 
detects  the  "mark"  returns  and  confirms  his  orientation  of  the  battle  area. 
He  is  now  positive  that  the  activity  he  had  detected  is  indeed  the  enemy 
advancement.  Yankee  Leader  drops  to  a lower  altitude  and  attempts  to 
transition  to  visual  operations.  Flying  directly  toward  the  enemy  line 
Yankee  Leader  visually  acquires  the  intended  target  area.  He  verifies  that 
guns  are  selected  and  notes  the  number  of  rounds  still  available.  He 
trains  his  sight  on  the  intended  target  area.  When  he  confirms  that  it 
is  in-range  he  begins  a series  of  short  bursts  along  the  enemy  forward 
line.  Detecting  a prominent  ground  flash,  he  immediately  assumes  infrared 
missile  launch,  breaks  off  his  attack  and  takes  advantage  of  his  craft's 
unique  maneuvering  capability  to  avoid  the  missile. 

Climbing  to  a safer  altitude,  he  sees  Yankee  Red  completing  his  attack. 

Both  Yankee  Leader  and  Yankee  Red  turn  for  one  more  attack  run.  Following 
this  strike  the  friendly  forces  take  advantage  of  the  temporary  confusion 
and  disorganization  to  launch  a counter-offensive  and  the  engagement 
becomes  too  confined  to  allow  any  further  air  support.  FAC(A)-Alpha 
releases  the  strike  aircraft  and  informs  the  Direct  Air  Support  Center 
(DASC)  which  releases  Yankee  Flight  for  a return  to  ship.  Yankee  Flight 
departs  on  the  pre-established  heading,  air-speed  and  altitude. 

Yankee  Leader  suddenly  receives  and  confirms  a threat  warning,  that  he 
is  being  illuminated  by  a tracking  radar.  Displayed  information  indicates 
the  source  of  the  illuminati^i  and  a recommended  action.  He  performs 
countermeasure  operations  and  makes  a quick  visual  search  for  a possible 
missile  launch  or  even  an  in-flight  missile.  He  sees  nothing.  He  receives 
a higher  priority  warning  that  the  emitter  is  closing.  Since  Yankee  Leader 
cannot  see  the  missile,  he  instinctively  rolls  into  a very  sharp  break-off. 
Pulling  out  at  low  altitude,  he  finds  that  he  has  broken  track  and  elects 
to  dash  to  the  coast  at  terrain  following  altitude.  Feet  wet,  Yankee 
Flight  climbs  to  a greater  altitude,  selects  local  air  control  frequency, 
and  activates  homing  aids  for  the  return  to  ship.  SCS-81  Combat  Informa- 
tion Center  contacts  Yankee  Flight  and  reports  that  CIC  is  tracking  them 
on  radar.  Avionics  are  selectively  shut  down,  vertical  take-off /landing 
mode  is  selected  on  the  primary  flight  display,  and  transition  to  vertical 
flight  is  accomplished.  Yankee  Leader  executes  a vertical  landing,  taxis, 
and  shuts  down. 
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Gross  Time  lino 

A gross  timeline  for  the  various  mission  phases  can  be  established  at  this 
point.  Inspection  of  the  mission  profile  will  identify  selected  mission 
elements  (e.g.,  take-off)  for  which  time  constraints  can  be  estimated.  The 
scenario  provides  additional  time  related  information  from  which  estimates 
or  actual  time  constraints  as  imposed  by  the  mission  can  be  determined. 

With  such  information,  both  the  general  mission  profile  (Figure  2.2-4) 
and  the  pictorial  scenario  (Figure  2.2-5)  can  be  adjusted  to  reflect  time 
constraints . 

The  resulting  gross  time  line  is  illustrated  in  Figure  2.2-6.  Refining 
of  timeline  information  will  be  a somewhat  iterative  process,  to  maintain 
current  information  on  both  absolute  and  inflexible  time  constraints  and 
to  establish  and  maintain  time  budget  estimates  and  constraints  as  relevant 
to  tiie  various  mission  phases. 

2.2. 1.3  Functional  Flow  Block  Diagrams 

Functional  flows,  in  block  diagram  format,  are  developed  from  the  mission 
profile.  These  flows  are  system  level  and  nonspecific,  i.e.,  they  are 
aircraft  system  and  function  oriented  to  define  functional  requirements 
for  operations  that  have  to  be  performed,  and  without  distinguishing  how 
they  are  to  be  performed  or  distinguishing  man  or  equipment  features. 
Examples  of  top  level  flows  are  presented  in  Figure  2.2-7,  illustrating 
the  segmented  nature  of  the  flows,  with  clearly  distinguishable  self- 
contained  functions.  Each  of  the  top  level,  main  functions,  incorporates 
similarly  self-contained  and  diagrammable  subfunctions.  These  are 
reflected  appropriately  in  flow  diagrams  which  also  reflect  successive 
levels  of  indenture,  or  can  be  reflected  in  an  outline  format.  The  next 
level  of  indenture  for  representing  overall  mission  functions/operations 
are  shown  in  Figure  2.2-8,  and  more  detailed  levels  for  representative 
pre-flight  activities  are  illustrated  in  TabLe  2.1-6.  Another  approach 
for  both  the  profile  and  functions  analysis  for  representative  landing 
operations  that  are  applicable  to  all  aircraft  (i.e.,  common  functions) 
is  presented  in  Figures  2.2-9,  2.2-10  and  2.2-11.  Still  another,  more 
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TABLE  2.1-6  (Continued) 


1.3  Bring  Required  Equipment  on  Line 

1.3.1  Acquire  System  Readiness 

1.3. 1.1  Activate  Vehicle  Subsystems 

1.3. 1.1.1  Propulsion 

1.3. 1.1. 2 Electrical 

1.3. 1.1. 3 Fuel 

1.3. 1.1. 4 Hydraulic 

1.3.1. 1.5  Fire  Control 

1.3. 1.1. 6 Environmental  Control 

1.3. 1.1. 7 Life  Support 

/ 1.3. 1.1. 8 Communications 

1.3. 1.1. 9 Navigation 

1.3.1.1.10  Additional  Displays 

1.4  Final  Pre-Flight 

1.4.1  Verify  Vehicle  and  Crew  Status 

1.4. 1.1  Monitor  Vehicle  Subsystems 

1.4. 1.1.1  Warning  Displays 

1.4. 1.2  Verify  External  Readiness 

1.4. 1.2.1  Ground  Control  Clearance 

1.4. 1.2. 2 External  Vehicle  Restraint 

1.4. 1.2. 3 Ground  Crew  Readiness 
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FIGURE  2.2-9:  TERMINAL  AREA  OPERATIONS  - 

REPRESENTATIVE  APPROACH/GO-AROUND 
CONDITIONS 
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FIGURE  2.2-11:  APPROACH/LAND  - NEXT  LEVEL  FUNCTIONAL  FLOWS 

FOR  STRAIGHT-IN  APPROACH 
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2.2. 1.3  (Continued) 

basic  approach  with  broader  utility,  that  might  be  applied  to  improve 
flexibility  is  shown  in  Figure  2.2-12  and  Table  2.1-7,  reflecting  summary 
information  for  f unction-action-informat  ion  indentures  for  a possible 
refueling  operation  in  event  the  CAS  mission  is  modified  to  include 
refueling.  (A  complete  tabulation  of  receiver  refueling  requirements  is 
presented  in  Appendix  A.)  This  approach  is  preferred  as  being  most 
generally  applicable,  particularly  for  the  type  of  uses  envisioned  for 
CAFES.  As  is  evident,  functional  flows  progress  through  a logical  refine- 
ment and  breakdown  reflected  by  several  levels  of  indenture  to  establish 
an  extensive  baseline  definition  of  system  functional  performance  require- 
ments. These  requirements  are  to  be  developed  to  the  lowest  and  most 
detailed  level  of  indenture  without  regard  to  distinctive  implementation 
modes,  hardware  concepts  or  man/equipment  features  and  trade-offs. 

The  functional  flow  analyses  may  be  carried  to  any  necessary  level  of 
indent  u re  to  appropriately  reflect  the  systematic  structuring  of  all 
functional  requirements.  When  complete,  they  relate  the  following 
necessary  element  of  information: 

1)  Mission  phase 

2)  Phase  function 

3)  Function  activity 

4)  Man-machine  interface  action-information  units  to  satisfy 
activity 

5)  Task  characteristics  that  can  be  associated  with  each 
action-information  unit 

Functions  and  subfunctions  are  reviewed  and  analyzed  in  depth  for  probable 
variations  related  to  the  system  requirements  and  operations.  Even  during 
early  development,  both  alternative  mission  requirements  and  the  expected 
downstream  developmental  impact  of  such  alternatives  are  appraised  to 
produce  an  early  gross  estimate  of  likely  crew  interface  requirements, 
capability,  special  provisions  needed,  potential  problems  and  probable 
solutions.  In  some  cases,  the  human  factors  analyst  may  also  need  to 
produce  preliminary  workload  data  and  to  provide  information  for  manning 
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FIGURE  2.1-7  (CONTINUED):  FUNCTIONAL  FLOW  INDENTURES 

FOR  REFUELING 


2.2.  1.3 


(Cont inued) 


and  training  estimates.  At  any  rate,  he  must  anticipate  a wide  variety 
of  both  normal  and  mission-specific  possibilities  to  form  a judgement 
for  crew  performance  feasibility,  support  requirements  and  development 
needs. 

In  summary,  functional  flows  provide  a detailed  and  comprehensive  inventory 
of  all  system  requirements  and  an  extensive  checklist  of  system  functions 
and  considerations  that  rust  be  considered  in  assuring  ability  to  perform 
the  mission.  Properly  structured,  the  inventory  will  proceed  from  func- 
tional indentures  common  to  all  similar  systems  (e.g.,  aircraft),  through 
indentures  peculiar  to  an  aircraft  type  (e.g.,  fighters)  and  on  to  func- 
tional elements  that  are  specific  to  mission  operations.  Detailed  analysis 
of  the  functions  is  required  to  determine  basic  methods  of  achievement, 
possible  equipments,  and  man-equipment  trades  in  order  to  effectively 
determine  which  elements  should  be  performed  by  equipment  and  which  should 
be  performed  by  man. 

The  key  element  of  the  functional  flow  analysis,  for  computerized  storage 
and  use,  is  the  logical  chain  of  carefully  developed  and  clearly  distinct 
functional  requirements  at  each  level  of  indenture.  At  the  top  level, 
a logical  chain  of  unique  functions  is  synthesized  to  meet  a more  gross 
functional  need  that  could  be  titled  "Complete  Mission."  Conversely, 
each  top  level  function  establishes  a functional  requirement  that  includes 
lower  level,  similarly  unique  and  self  contained  sub-functions  which  define 
all  necessary  and  related  elements  to  satisfy  its  needs.  This  process 
carries  on  down  through  more  and  more  detailed  functions  until  all  possible 
elements  are  ident if ied, as  available  and  identifiable  performance  objec- 
tives/criteria that  can  be  associated  with  the  functional  elements. 

Carried  through  the  lowest  level  of  indenture,  the  functional  flows  will 
incorporate  extremely  specific  actions  that  must  be  performed  to  satisfy 
the  functional  requirement,  and  information  that  must  be  available  to 
perform  the  related  actions.  The  result  is  an  extremely  detailed  and 
comprehensive  inventory  of  every  possible  requirement  for  the  mission. 

At  this  level  of  detail,  there  is  less  question  as  to  what  candidate 
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2.2. 1.  3 


(Cont inued ) 


equipment  wil'.  satisfy  the  need,  if  in  fact  such  equipment  exists  (which 
is  more  readiiy  apparent).  Similarly,  there  are  fewer  judgemental  factors 
in  identifying  and  performing  specific  man-equipment  capability  trade-offs 
for  a functions  allocation. 

Effectiveness  of  this  particular  activity  is  one  of  the  most  critical  to 
establishing  a standard  baseline  for  any  system  (e.g.,  airplane)  for  use 
of  CAFES.  It  is  also  one  of  the  most  difficult  in  terms  of  maintaining  a 
consistent  and  logical  chain  in  the  structural  breakdown.  Most  frequently, 
the  tendency  is  to  skip  the  logically  structured  chain  of  requirements  and 
indentures  and  to  get  to  specific  hardware  applications  concepts  as  rapidly 
as  possible.  In  this  circumstance,  the  result  may  be  unique  to  the  system, 
the  analyst  or  to  the  specific  system  concept  at  hand, and  may  lack  the 
required  generality  for  repeated  use.  Accordingly,  a whole  new  develop- 
ment may  become  necessary  for  each  new  analyst  or  new  system.  (One  such 
contrast  was  reflected  in  the  distinctions  in  the  functional  flows  for 
Figure  2.2-8  and  the  associated  indentures  of  Table  2.1-6,  in  comparison 
with  a similar  intent  for  Figure  2.2-12  and  Table  2.1-7,  which  is  con- 
tinued in  Appendix  A.) 


2-2. 1.4 


Func  t ion- Act  ion- Informat  ion  Requirements 


The  analytic  procedures  for  performing  preliminary  functions  analyses  are 
dependent  on  the  analyst  and  his  objectives.  Several  alternatives  exist 
for  this  particular  analyses,  e.g.,  to  make  the  allocation  from  the  level 
of  the  detail  provided  by  the  functional  flows.  However,  experience  has 
shown  that  more  task-related  detail  is  desirable  before  making  allocation 
trades.  A format  that  has  been  useful  in  producing  this  detail  in  an 
appropriate  context  is  system  "action-information  requirements"  (Figure 
2.2-13)  or  to  carry  this  even  further  and  reflect  associated  trade-off 
information  and  data  (Figure  2.2-14).  The  action-information  requirements 
define  the  specific  actions  necessary  to  perform  a function  and,  in  turn, 
those  specific  information  elements  that  must  be  provided  to  perform  the 
action.  Another  format  is  to  define  the  action-information  requirements 
as  extensions  and  part  of  the  functional  flows  (i.e.,  as  more  detailed 
levels  of  indenture). 
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FIGURE  2.2-13: 


FUNCTIONAL  ANALYSIS,  REPRESENTATIVE  DEVELOPMENT  OF  ACTION/ INFORMATION 
RFOUTRKMENTS  (ADAPTED  FROM  REFERENCE  44) 
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2. 2. 1.4 


(Continued) 


The  resulting  level  of  detail  leads  to  the  identification  of  specific 
functional  elements  for  allocation.  Additionally,  the  particular  develop- 
ment chat  has  been  presented  in  the  preceding  outline  and  figures  can  be 
developed  for  a general  purpose  basic  format,  emphasizing  fundamental  opera- 
tions that  are  not  hardware  specific  (Figures  2.2-9  through  2.2-14).  As  is 
apparent,  a number  of  relevant  trades,  decisions  and  candidate  allocation 
concepts  can  be  identified  with  early  and  preliminary  definition  of  system 
requirements . 

2. 2. 1.5  Candidate  Control-Display  Equipments  Identification 

Candidate  equipment  can  be  identified  and  listed  tentatively  for  every 
detailed  requirement  indicated  by  the  functional  flow  and  action-information 
requirements.  These  candidates  would  cover  all  possibilities,  including 
functions  that  are  common  to  all  such  systems  (e.g.,  aircraft)  and  to  a 
type  (fighters)  as  well  as  those  functions  that  are  mission  specific.  To 
the  extent  that  functional  requirements  indicate  a performance  objective 
or  criteria,  the  extent  of  equipment  ability  to  satisfy  the  requirement 
can  also  be  appraised.  Equipment  ability  to  satisfy  several  related  or 
alternative  requirements  can  also  be  identified.  Finally,  each  piece  of 
equipment  has  associated  with  it  detailed  task  requirements.  Accordingly, 
detailed  task  information  is  determinable  for  trade-offs  related  to 
completing  functions  allocations,  for  identifying  task  performance  problems, 
for  possible  new  concepts  involving  equipment-task  integration,  and  for 
all  subsequent  phases  of  HFE  efforts. 

In  summary,  equipment  characteristics  related  to  detail  functions  can  be 
identified  and  data  obtained  or  made  available  to  the  extent  that  r ight 
be  required  for  functions  allocation  trade-offs.  Several  trade  charac- 
teristics, features  and  possibilities  become  more  readily  apparent  at  this 
level  of  detail,  e.g.,  equipment  reliabilities,  capabilities;  man-machine 
interface  features;  and  related  crew  performance  requirements  (including  such 
features  as  task  elements,  complexity,  time  accuracy  and  reliability); 
dimensions;  weight;  and  cost. 
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Crew-Equipment  Functions  Allocution 


At  this  point,  particularly  with  functional  flow,  uni  .n  i ion-informal  ion 
requirements  carried  to  quite  detailed  levels  and  candidate  equipments 
and  characteristics  identified,  the  analyst  will  have  the  necessary  infor- 
mation to  perform  a credible  series  of  trade-offs  to  allocate  1 unctions  to 
man  and  machine. 

With  the  present  HFE  technological  stare-o f-ar t , there  is  no  clearly 
definable  way  to  outline  all  analyst  decisions,  operations  and  constraining 
man-equipment  interface  elements  that  might  be  involved  in  performing  a 
functions  allocation.  The  allocation  process  can  be  described,  past 
experience  and  allocations  can  be  used,  and  historical  results  can  be 
applied.  Programmable  features  for  data  retrieval  and  processing  can  be 
used  to  support  this  process  and  to  validate  results,  or  to  compare  alter- 
native allocations.  However,  the  ultimate  decision  and  responsibility 
will  remain  with  the  analyst;  he  may  accept  the  prior  data  or  may  choose 
an  alternative  because  of  some  special  mission  feature  or  objective. 

Following  discussion  summarizes  information  to  be  considered  and  describes 
an  approach  to  performing  the  allocations.  As  a precautionary  note,  the 
actual  quality  of  results  in  application  will  be  dependent  on  the  level  of 
detail  available,  and  will  involve  the  technical  knowledge  and  expertise 
of  the  analyst.  However,  the  burden  on  the  analyst  will  be  reduced 
dramatically  if  preceding  detailed  information  is  available,  and  can  be 
reduced  much  further  if  an  analytic  method  of  confirming  allocations  is 
applied  for  preliminary  allocation  concepts  (e.g.,  The  Functions  Allocation 
Model  and  The  Workload  Analysis  in  CAFES). 

In  performing  the  actual  allocation,  the  analyst  can  proceed  systematically 
through  all  functional  requirements  and  identify  special  or  optional  alloca- 
tions covering  candidate  equipments  to  suit  the  need.  Alternatively,  he 
might  identify  new  equipment  or  automation  concepts  that  hear  consideration 
or  might  be  required,  either  to  satisfy  the  mission  or  to  integrate  selected 
requirements.  Specific  assumptions  that  may  be  involved  in  performing 
functions  allocations  may  also  relate  to  general  objectives  or  require- 
ments such  as  variations  in  desired  crew  size  and  skills  or  the  possibility 
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of  intracrew  task  sharing.  Judgements  that  may  be  required  can  vary 
dramatically;  a range  of  parameters  such  as  are  indicated  in  Table  2.1-8 
may  bear  consideration.  Additionally,  application  of  such  trade-offs  as 
are  il Lustrated  by  the  "Fitt's  List"  comparisons  of  manb  capabilities 
versus  equipment  capabilities  (Table  2.1-9)  will  be  involved.  Also,  t lie 
man-machine  interface  characteristics  that  were  outlined  in  Table  2.1-3 
will  be  elements  in  such  judgements. 

Resulting  allocations  will  remain  to  be  verified  in  terms  of  such  varia- 
tions as  probable  success,  crew  number  and  skills,  operational  feasibility, 
and  suitability.  Limitations  in  past  applications  have  been  in  the  areas 
of:  detail  definition  and  consideration  of  all  requirements,  confirming 

that  all  possible  requirements  are  met,  providing  specific  consideration 
and  comparisons  of  viable  options,  or  establishing  variations  in  levels  of 
automation  that  might  be  desirable.  Use  of  quantitative  methods  to 
perform  specific  allocation  trade-offs  has  varied.  Finally,  verifying 
suitability  of  allocations  analytically  has  tended  to  rely  on  detailed 
time  line  analyses  and  workload  estimates  (with  iterative  use  of  mockups 
and  various  levels  of  man-in-loop  simulation). 

Eventual  completion  of  initial  allocations  are  somewhat  interactive  with 
all  subsequent  activities.  As  performance  of  the  analyses  described  later 
discussions  indicates  a problem  area,  resolution  of  the  problem  may  well 
require  re-examination  of  the  initial  allocations. 


2.2.1. 7 


Gross  Definition  of  Intracrew  Tasks 


Initial  allocation  of  specific  tasks  to  a given  crewman  is  the  responsi- 
bility of  the  human  factors  analyst.  This  initial  task  assignment  may 
be  done  on  traditional  or  experience  grounds  according  to' similar  activities 
performed  in  like  vehicles.  This  allocation  provides  the  basis  for  assessing 
time  line  feasibility  crew  interactions  for  crew  workload. 

In  early  phases  of  system  development,  the  human  factors  analyst  is  most 
interested  in  gross  capability  of  given  hardware  systems  to  perform  the 


TABLE  2.1-8 


PERSONNEL/SKILL  ASSUMPTION 


I 


CKNhRAL 

Type 
Skills 
Skill  l.rve : 

Tr.il  nln:*.  H.*qui  rcineuts 
Procedure  ■ 

Backy.t  outul 
Experience 
Fducat ion 


Response  Character  1st ics 
Quant  I r y 
Decree 
Type 
Lew  1 
Time 

Accuracy 
Interference 
Rat  lugs 
Etc. 

A 1 ternnt Ives 
Practical  Trade— Offs 
Other 


MECHANICAL 

Physical  Condition 
Size 

Strength 
Coord inac ion 
Skill  Level 
Ai ternnt i ves 
Practical  Trade-Offs 

^ Other 


1 

< 

f 


SENSOR  MOTOR 

Vi  s i on-Acu i tv 

Depth  Perception 
Contrast  Perception 
Color  Perception 
Response  Tine 
Physiology 
Pattern  Recognition 
Other 


And i r i on-Acu i t y 

Tone  Discrimination 
Loudness  Perception 
response  line 
Phys  iolcgy 
Ot  her 


Tac  t i le-Acui ty 
Discriminat ion 
Response  Time 
Other 
Ot  he  r 

Al ternat Ives 
Practical  Trade-Offs 


Motor 

Skills 

Strength  Force 
Dexter i ty 
Compatibi 1 i ty 
Sensi tivi ty 
Other 


PERSONALITY  AND/OR  CAPABILITY 


Apt  1 tude 

Mot i vat  ion 

At  t i tude 

Ten;  er ament 

Dec  i>.  iveness 

Adap tab i 1 i tv 

Analytic  Capability 

Objectivity 


Idiosyncrasies 
General  Personality 

IQ 

Pr  i r i c * 1 Trade- Ot t s 
Other 


■ 


i 

V 


* 

t 


L 
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MAN  VS. 


MACHINE 


MAN  EXCELS  IN- 


MACHINES  EXCEL  1 N 


Detection  of  certain  forms  of  very 
low  energy  levels 

Sensitivity  to  an  extremely  wide 
variety  of  stimuli 

Perceiving  patterns  and  making 
generalizations  about  them 

Detecting  signals  in  high  noise 
levels 

Ability  to  store  large  amounts  of 
information  for  long  periods  - 
and  recalling  relevant  facts  at 
appropriate  moments 

Ability  to  exercise  judgment 
where  events  cannot  be  completely 
defined 

Improvising  and  adopting  flexible 
procedures 


Ability  to  react  to  unexpected 
low-probability  events 

Applying  originality  in  solving 
problems:  i.e.,  alternative 
solutions 

Ability  to  profit  from  exped- 
ience and  alter  course  of  action 

Ability  to  perform  fine  manipula- 
tion, expecially  where  misalignment 
appears  unexpectedly 

Ability  to  continue  to  perform 
when  overloaded 


Monitoring  (both  men  and  machines) 

Performing  routine,  repetitive,  or 
very  precise  operations 

Responding  very  quickly  to  control 
signals 

Exerting  great  force,  smoothly  and 
with  precision 

Storing  and  recalling  large  amounts 
of  information  in  short  time- 
periods 

Performing  complex  and  rapid 
computation  witli  high  accuracy 

Sensitivity  to  stimuli  beyond  the 
range  of  human  sensitivity  (infra- 
red, radio  waves,  etc.) 

Doing  many  different  things  at 
one  time 

Deductive  processes 


Insensitivity  to  extraneous  factors 

Ability  to  repeat  operations  very 
rapidly,  continuously,  and  pre- 
cisely the  same  way  over  a long 
period 

Operating  in  environments  which  are 
hostile  to  man  or  beyond  human 
tolerance 


Ability  to  reason  inductively 


TABLE  2.1-9:  "FITT'S  LIST"  COMPARISON  OF  MAN’S  CAPABILITIES  VERSES  EQUIPMENT 

CAPABILITIES  (From  Reference  46) 
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2.2. 1.7  (Continued) 

function  and  gross  man-equipment  capability  features  affecting  performance. 
The  analyst,  to  perform  liis  job  most  effectively,  needs  extensive  data 
for  review  and  preliminary  decisions.  Me  frequently  must  anticipate  the 
detailed  impact  of  the  functions  to  be  performed  as  the  influence  control/ 
display  requirements,  selection,  and  performance  features.  Such  infor- 
it  ion  dot  ines  detailed  crew  tasks  and  workload. 


1 ia.  r ion. 1 1 flows  and  functions  analyses  provide  a comprehensive  organiza- 
tion of  all  mission  functions,  from  which  gross  function  allocations  and 
intracrew  assignments  may  be  made  if  desirable  or  necessary.  Alternatively, 
the  analvst  may  wish  to  perform  the  allocation  and  evaluate  the  timeline 
and/or  workload  implications,  from  which  crew  number  requirements  could 
be  appraised  (or  alternatively,  specific  needs  lor  increased  automat  is. 
could  be  deduced).  Such  activities  refine  the  baseline  for  efforts 
relating  to  crew  task  definitions,  control,  display,  and  operations 
requirements,  crew  station  configuration  concepts,  workload  evaluation-., 

< crew  station  design,  development  evaluation,  and  the  training,  manning, 

and  procedures  requirements. 

The  human  factors  engineering  analyst,  at  this  point,  has  a detailed  and 
well  organized  inventory  and  checklist  of  system  functions  to  be  performed, 
a correlated  analysis  of  functional  requirements,  alternative  allocation 
concepts  and  associated  task  requirements.  The  analyst  must  be  able  to 
convert  these  functions  into  specific  man-equipment  integration  require- 
> ments  and  concepts,  and  to  refine  any  additional  data  requirements  for 

more  specific  definition  of  hardware  items  and  tasks  required  of  the 
crewman.  The  Identification  of  the  equipment,  the  tasks,  the  sequence  of 
tasks,  d the  operations  then  become  the  basis  for  developing,  comparing 
and  evaluating  candidate  crew  station  concepts. 

2. 2. 1.8  Operational  Sequence  Diagrams  (OSD’s) 

OSD’s  are  often  applied  around  this  point  in  developmental  analyses 
(Figures  2.2-2;  2.2-1).  The  method.  Illustrated  in  Figure  2.2-15,  is 
useful  in  tracking  system  information  flow  and  decisions  between  crewmen, 

t! 
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between  subsystems  and  between  the  men  and  equipment,  e.g,,  the  transfer 
at  the  man-equipment  interface.  It  provides  for  assuring  that  there  are  no 
open  loops  in  the  chain  of  events  involved  in  accomplishing  a given  func- 
tion, and  for  verifying  that  the  requirements  are  suitably  met.  It  can  be 
particularly  useful  in  performing  detailed  evaluations  of  critical  task 
events  or  for  critiquing  detailed  characteristics  of  the  man-equipment 
interface.  For  example,  events  and  activities  associated  with  a critical 

task  can  be  traced  back  and  forth  between  subsystems,  between;  subsystems 

/ 

and  operators,  and  between  operators.  With  s h detail,  the  analyst  can 
verify  that  the  solution  is  appropriate,  that  all  necessary  features  of 
interface  inputs  and  outputs  are  present,  and  that  he  comprehends  the  over- 
all operation.  Accordingly,  he  has  the  necessary  information  to  isolate 
specific  elements  in  the  flow  that  are  of  import  to  the  crew,  and  to  eval- 
uate suitability  of  the  man-equipment  interface  (including  the  type  of 
requirement,  effectiveness  of  the  man  at  performing  the  requirements,  and 
appropriateness  of  interface  design  features  for  effective  performance). 

In  actual  practice, use  of  OSD's  is  a variable  related  to  analyst  pre- 
ference. Through  functions  and  task  analysis  or  through  formal  OSD  development 
the  intent  is  accomplished  by  the  analyst.  As  illustrated  in  the  represen- 
tative diagram,  the  method  is  formal,  detailed  and  laborious.  Conversely, 
it  is  feasibLe  to  use  the  method  at  grosser  levels,  and  some  analysts  use 
it  in  such  a way.  Regardless  of  analyst  preferences,  there  is  general 
agreement  that  OSD's  are  useful  for  those  operations  analyses  involving 
critical  tasks  or  interactions  among  several  crew  members. 

2.2. 1.9  Task  - Workload  Analysis 

The  primary  purpose  of  a task  analysis  or  a workload  analysis  is  to  confirm 
that  task  requirements  can  be  met  without  undue  difficulty  and  do  not 
involve  conflicting  demands  on  the  crewman;  that  provisions  for  task 
performance  are  effective;  and  that  time  and  workload  conditions  are  such 
that  there  is  an  adequate  margin  of  task  time  to  perform. 

Task  analysis  includes  task  definition,  covering  crew  actions,  information 
requirements  and  crew  performance  capabilities  vs.  controls,  displays 
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associated  crew  performance  requirements.  Three  elements  accrue:  (1)  an 
appraisal  of  task  difficulty,  feasibility,  and  skills  for  refining  control/ 
display  concepts  and  feedback  to  earlier  orocesses;  (2)  task  sequencing, 
time  and  timeline  feasibility;  (3)  initial  control-display-crew  operations 
requirements . 

Task  analyses  objectives  are  to  complete  and  refine  crew  task  definition  and 
task  data.  Initially,  this  consists  of  converting  functions  allocated  to 
the  crew  and  control-display  implications  to  task  requirements  and  features. 
These  task  elements  are  evaluated  to  assure  adequate  provisions  for  effec- 
tive crew-equipment  performance  of  each  task.  Basic  task  feasibility  is 
evaluated,  constraints  for  man-machine  interface  operations  are  identified, 
and  associated  design/development  needs  are  specified.  Potential  man- 
equipment  combinations  are  evaluated  for  the  type  of  crew  performance  fea- 
tures (e.g.,  skills,  perceptual  motor)  that  are  involved.  Limitations  are 
further  appraised  for:  system  performance  implications,  practical  signi- 
ficance of  such  implications;  possible  reallocation;  or  possible  resolution 
by  control-display  design  features.  As  limitations  are  resolved,  control- 
display  refinements  and  operations  requirements  are  specified. 

DETAILED  TASK  TIMELINE 

The  detailed  mission  timeline  provides  the  base  for  evaluating  both  feasi- 
bility of  task  completion  in  time  and  of  resulting  crew  member  workloads. 

It  provides  for  identification  and  correlation  of  the  individual  crew  tasks, 
the  order  of  execution,  and  the  estimated  time  elapsed. 

Initial  mission  timelines  described  earlier  (section  2. 2. 1.2)  amounted  to 
gross  task  definitions,  to  begin  the  comparison  of  candidate  equipment/man 
function  allocations.  The  -initial  evaluation  of  the  timeline  is  similar 
to  the  top  level  indenture  of  a functional  flow  block  diagram,  in  that 
many  tasks  and  individual  elements  are  grouped  into  relatively  long  time 
frames  in  order  to  assess  the  impact  for  a crewman  over  the  total  mission 
segment.  Successive  iterations  tend  to  concentrate  on  those  segments  of 
the  mission  which  have  critical  time  frame  limits,  critical  work  loads, 
critical  activities  requiring  intense  and  all  encompassing  concentration 
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of  the  crew,  or  those  activities  with  elements  whose  execution  is  mandatory 
for  successful  completion  of  the  mission  segment  under  investigation. 
(Figure  2.2-6  illustrates  an  initial  timeline  evaluation  at  the  mission 
phase  level;  Figure  2.2-16  illustrated  a detailed  second  by  second  time- 
line evaluation.) 

The  timeline  is  a chronological  listing  of  the  events  expected  to  occur 
during  the  execution  of  a mission  or  mission  segment.  The  human  factors 
analyst  is  required  to  specify  tasks  to  be  accomplished  and  the  duration 
of  the  activity,  and  time  constrained  limits. 

Considerable  data  on  task  execution  times  are  available  in  tie.-  literature, 
human  engineering  books  and  Industrial  Engineering  sources.  however, 
these  data  may  not  be  available  in  sufficient  detail  to  assure  dirts  t 
applicability.  In  most  instances  it  is  necessary  for  the  human  factors 
analyst  to  improvise  or  synthesize  performance  time  data  to  be  able  to 
complete  the  timeline.  The  data  and  methods  described  in  the  Data  Store 
produced  by  the  American  Institute  for  Research  may  also  be  useful  in 
this  regard.  Limitations  in  current  data  will,  hopefully,  be  corrected 
as  the  fund  of  knowledge  continues  to  build.  Each  systems  development 
program  should  provide  some  additional  information  that  can  enhance  a 
data  storage  system. 

Based  on  representative,  similar  equipment  and  the  type  and  number  of 
operations  or  on  expected  equipment  features,  data  used  may  be  from 
empirical  measurements  for  such  equipment  in  a mockup  or  simulator,  or 
from  an  analytic  accumulation  of  the  time  required  to  perform  distinct 
operations  with  the  representative  equipment  (e.g,,  to  adjust  knob,  flip 
switch,  push  button).  If  there  is  no  similar  equipment,  it  may  become 
necessary  to  estimate  from  similar  task  elements  on  other  equipment,  or 
through  mockup  or  simulation  approximations  of  the  activities  in  order  to 
produce  time  estimates.  Alternatively,  if  specific  equipment,  related 
task  events  and  task  sequences  are  available,  analytic  or  mockup-simulat ion 
data  should  be  readily  obtainable. 
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At  any  rate,  and  particularly  for  tasks  in  critical  mission  portions, 
initial  estimates  or  data  will  require  refinement  to  the  extent  more 
specific  equipment  features  and  operational  procedures  are  identified 
during  system  development.  As  detailed  equipments  and  operations  are 
defined  in  early  analyses,  related  timelines  will  be  reasonably  stable. 
However,  time  to  perform  may  be  influenced  by  relative  physical  location 
of  equipments  in  the  crew  station.  Additional  examination  of  critical 
events  may  be  desirable  when  crew  station  configuration  concepts  are 
def ined . 

WORKLOAD  ANALYSIS 

Earliest  possible  workload  appraisals  are  needed  to  assure  that  resulting 
task  loads  are  within  the  scope  of  crew  size  and  capability.  Workload 
analysis  is  performed  to  determine  if  the  accumulation  of  tasks  per  unit 
time  can  be  performed  by  the  crewman.  The  objective  of  such  an  analysis 
is  to  verify  that  no  combination  of  tasks  required  of  the  operator  take 
more  task  load  capacity,  skills,  or  time  to  perform  than  is  available. 
Workload  as  a descriptor  of  effort  has  been  a controversial  term,  primarily 
because  of  the  number  of  variables  that  might  be  considered  to  be  involved. 
Quantification  of  effort  for  applications  as  desired  here  has  been  difficult. 
Such  related  measurement  as  energy  expended,  heart  rate,  physical  activity 
and  many  other  elements  are  not  readily  responsive  to  short  term  workload 
peaks  for  measurement  purposes,  and  are  not  readily  usable  as  predictors 
for  short  time  multi-task  events.  More  definitive  research  may  be 
desirabLe,  but  a more  pragmatic  application  to  present  systems  programs 
has  been  needed. 

Industrial  Engineering  time  and  motion  methods  provided  the  framework  for 
a concept  which  has  been  used  in  elementary  manual  applications.  Using 
the  task- time  1 ine  base,  percent  workload  judgements  have  been  made  as  to 
the  extent  of  mental  and  physical  effort  or  commitement  involved  at  incre- 
mental units  of  time.  Such  features  as  detailed  task  characteristics  and 
their  "load”  (tasks  that  overlapped  each  other  in  Lime)  and  known  "work- 
load" problem  areas  (from  past  experience)  could  be  used  to  appraise  the 
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relative  workload  for  a new  concept.  In  application,  the  analyst  could 
make  informed  judgements  about  both  the  amount  of  crew  "involvement"  and 
the  amount  of  reserve  capacity  that  might  remain,  and  then  chart  estimated 
workload  levels.  Reasonable  agreement  between  analysts  is  generally 
observed  in  the  results  from  this  methodology. 

Basic  principles  and  procedures  have  been  developed  which  permit  workload 
comparisons  between  system  concepts.  One  such  method  recognizes  that  an 
operator  simultaneously  performs  several  functions  in  accomplishing  a 
single  task,  i.e.,  visual  auditory,  cognitive,  and  physical  motion  (e.g., 
right  hand,  left  hand,  amount  of  travel).  The  point  is,  effective  evalua- 
tion of  workload  requires  recognition  of  the  fact  that  several  operator 
"channels"  are  involved  in  a task,  and  conversely  other  "channels"  are 
relatively  free  for  performance  of  other  tasks. 

Improved  methodology  was  desirable.  However,  computer  capabilities  were 
necessary  to  most  fully  develop  this  methodology.  The  CAFES  Workload 
Analysis  Model  is  the  present  evolutionary  stage  of  this  method. 


2.2.1.10 


Crew  Station  Configuration  Concepts,  Trade-Offs  and  Design 


Initial  objectives  for  this  evolutionary  process  are  to  identify  and  eval- 
uate feasible  crew  station  configurations  to  select  a specific  concept. 

Such  objectives  phase  into  the  physical  design,  development  and  evaluation 
of  a given  configuration.  Typically,  this  process  has  been  starting 
simultaneously  with,  or  even  preceeding  the  HFE  analyses.  More  ideally, 
it  should  follow  the  analyses. 

In  early  stages,  the  crew  station  designer  should  have  at  least  such  infor- 
mation as  (a)  the  mission  requirements,  candidate  control-display  equipments, 
internal  and  external  vision  requirements,  correlated  task  requirements, 
crew  visual-physical  access  needs,  seating  and  ingress/egress  needs  and 
possible  crew  complements;  (b)  specifications,  standards  and  design  hand- 
book requirements,  covering  the  full  range  ot  crew  station  design  variables; 
(c)  approximate  dimensions  and  arrangement  of  the  unoccupied  space; 
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(d)  general  ground  rules  to  work  bv,  such  as  criticality  of  a task  or 
operation,  frequency  ot  use  and  functional  grouping  of  controls  and  displays, 
and  (e)  anthropometry  of  the  operators,  and  (l)  more  or  less  standardized 
design  practices,  based  on  experience,  comparable  systems  and  analogeous 
situations.  For  example,  the  requirements  in  Military  Standard  MIL-H-1472 
are  relevant  throughout  this  process.  From  such  inputs,  and  from  his 
ingenuity  and  ability  to  conceive  new  concepts  or  alternatives  that  satisfy 
the  needs,  he  effects  the  necessary  compromises  and  integrations  to  develop 
candidate  conf igurat >.ons.  These  are  typically  refined  during  development 
of  preliminary  drawings,  and  "soft”  mockups  are  used  for  further  comparison, 
refinement  and  evaluation.  Multiple  critiques  from  multiple  viewpoints  are 
applied.  Use  of  the  mockups  may  vary  from  performing  individual  compliance 
checks  for  display,  control  or  arrangement,  through  evaluation  of  provisions 
for  a given  series  of  tasks,  to  an  evaluation  of  overall  effectiveness  by 
mentally  and  verbally  progressing  through  the  mission  scenario.  Improved 
or  new  concepts  may  also  be  mocked  up.  Selected  areas  may  be  further 
examined  by  transferring  evaluations  to  a part-task  simulation. 


The  eventual  result  from  the  various  critiques  and  evaluations  is  the 
selection  of  a specific  configuration  with  necessary  refinements.  With 
this  selection,  physical  design,  development  and  evaluation  undergoes 
continuing  iteration  of  any  of  all  prior  processes,  as  required  to  assure 
an  effective  crew  interface  is  evolving  that  meets  requirements  of  the 
developing  system  and  provides  for  necessary  crew  performance.  This  latter 
activity  phases  from  design  mockup  evaluations  through  increasingly 
representative  simulation  and  hardware  development,  and  proceeds  on  through 
flight  evaluations.  During  the  process,  the  configuration  becomes  firm 
and  less  responsive  to  system  design  changes  for  any  problems  and  solutions 
other  than  those  that  can  be  solved  by  procedure  changes  or  those  that 
involve  major  safetv-of-f light  items. 


All  these  activities  are  sufficiently  familiar  and  relatively  standard  in 
the  design  process,  so  that  there  is  no  need  for  extensive  discussion  of 
the  typical  problems  and  the  types  of  solutions  that  have  been  applied. 
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The  key  point  to  be  made  is  that  the  efforts  outlined  previously  will 
significantly  improve  on  the  typical  limitations  that  are  exposed  at  this 
development  stage. 


Results  lead  into  the  test  and  evaluation  program,  with  the  objectives  to 
demonstrate  that  the  overall  development  suitably  meets  mission  require- 
ments and  that  the  system  can  be  controlled,  operated,  maintained  and 
supported  by  trained  personnel. 


2.2.1.11 


Manning,  Training  and  Procedures  Requirements 


Cost  of  system  operation  and  maintenance  in  terms  of  personnel  is  directly 
and  demonstrably  reflected  in  these  elements.  Effectiveness  of  main  HFE 
provisions  will  show  up  in  this  area,  as  number  and  types  of  personnel, 
required  skill  levels,  and  extent  of  training  required. 


As  typical  system  programs  phase  into  operations,  large  complements  of 
personnel  with  appropriate  entrv  skills  must  be  preselected  and  trained, 
provided  with  necessary  (■■•rations  and  maintenance  handbooks,  and  prepared 
to  test,  evaluate  or  otherwise  apply  the  system.  Personnel  who  are 
knowledgeable,  prepared  and  equipped  must  be  ready  to  accept  each  hardware 
element  is  it  comes  off  thi  line  and  perform  any  and  all  related  functions. 
\ccordingly , and  in  parallel  with  design  and  fabrication  efforts:  personnel 

numbers  and  skills  are  established;  training  requirements,  planning,  courses 
and  instruction  are  defined  and  accomplished;  and  technical  publications 
providing  operation  and  maintenance  instructions  and  data  are  being  produced. 


Information  on  systems  and  related  tasks  provides  the  starting  point  for 
detailing  the  training  program  requirements,  selection  of  training  methods, 
and  both  identifying  and  initiating  development  of  required  training 
equipmen  t . 


In  order  to  meet  the  overall  requirements  and  have  qualified  personnel 
available  as  the  equipment  becomes  available,  manning,  training  and  pro- 
cedures specialists  must  forecast  many  of  the  hardware  developments  and 
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initiate  related  activities.  Earliest  possible  definition  ni  manning, 
training  and  procedural  requirements  is  required  in  order  to  structure 
the  programs.  Both  past  experience  with  similar  systems,  detailed  func- 
tional flows  and  other  analytic  results  are  reviewed  and  evaluated  for 
implied  operation  and  maintenance  needs.  Accordingly,  the  quality  of 
early  definition  is  dependent  on  the  level  of  experience  and  on  the  amount 
of  detail  provided  by  the  analytic  data.  Additional  definition  is  accom- 
plished as  design  decisions  are  made  and  ns  task  analyses  are  completed. 

Manning,  training,  and  procedures  requirements  interrelate  with  and  are 
dependent  on  the  type  of  data  provided  by  the  human  engineering  development 
of  task  and  equipment  data,  task-timeline  analyses  and  workload  analyses, 
and  are  directly  affected  by  corresponding  decisions.  Needed  data  includes 
all  elements  of  both  traditional  and  new  systems  tasks.  Manpower  levels 
and  skills  are  similarly  dependent  upon  tasks  and  task  structure.  Training, 
and  procedures  requirements  are  similarly  dependent  in  terms  of  (1) 
deriving  specific,  training  objectives  and  (2)  defining  requirements  for 
existing  and  new  skills,  curricula  needs,  and  training,  operations,  and 
maintenance  manuals. 

The  point  is  that  detailed  development  of  these  requirements  is  dependent 
on  HFF.  products  which  convey,  among  other  information  elements,  the  type 
and  difficulty  of  training  tasks.  If  such  information  is  not  available, 
the  training  analyst  must  reLy  heavily  on  past  experience  and  progressive 
design  decisions.  Most  typically,  the  HFE  analyst  and  the  training/ 
manning/procedures  specialist  are  working  in  parallel,  so  that  extensive 
coordination  is  required  to  maintain  currency  on  unpublished  information. 

As  tlie  analytic  process  moves  on,  the  HFE  is  producing  very  specific  .task- 
definitive  information.  Recording  and  transferring  this  information  provides 
the  detailed  data  that  can  be  used  to  develop  training  requirements  and 
objectives,  and  that  help  to  refine  manning  and  procedures  needs. 

i he  refinement  of  candidate  equipment  subsystems  and  components  during 
successive  iteration  of  crewstation  evaluation  helps  to  further  refine  the 
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type  of  training  functions  and  skill  mixes.  For  example,  the  specific 
activities  of  support  crews  will  be  partially  defined  once  equipment 
candidates  become  known.  The  equipment  candidates  will  have  associated 
replacement  maintenance  requirements  which  may  be  used  to  further  establish 
training,  manning,  and  procedure  requirements  for  support  and  maintenance. 

The  objectives,  depth  ind  detail  of  training  is  subject  to  judgement  by 
the  training  analyst,  just  as  much  of  the  selection  of  equipment  candidates 
for  an  unknown  developmental  system  is  subject  to  the  judgement  of  the 
human  factors  analyst.  He  can  make  extensive  use  of  developmental  infor- 
mation described  previously  in  this  report. 
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2.2.2  (IFF  Methods  and  Data  Requirements  - Desirable  Developments 

and  Improvements 

the  methodology  out  Iliad  in  preceding  portions  of  this  report  is  only  one 
oi  many  possible  approaches.  It  does  not  adhere  to  the  full  range  and 
sequence  of  techniques  that  arc  available  and  that  have  been  used.  However, 
it  has  been  applied  and  demonstrated  to  work  as  intended.  It  does  provide 
a vehicle  tor  systematically  narrowing  the  overwhelming  range  of  potential 
H F 1 considerations  to  specifically  structured  requirements  related  to 
spe  it  i mission  roles.  this  approach  helps  to  scope  and  constrain  the 
tvpe  tnd  quality  of  data  that  might  he  needed  for  those  kev  data  elements 
which  ar<  necessary  and  sufficient  to  make  appropriate  111’ K decisions. 

Several  HFK  data  requirement  concepts  emerge  from  the  approach  that  has 
been  described.  Ihe  following  discussion  highlights  six  major  data  areas 
that  have  been  identified  from  preceding  sections.  Discussion  then  turns 
to  a mots-  extensive  description  of  task  data  considerations  and  equipment, 
da  t a i ons  i tier  a t ions . 

2. 2. 2.1  ' Desirable  Developments 

First,  it  would  be  advantageous  to  have  available  for  ready  access  and  use 
generalized  mission  scenarios  and  a full  set  of  representative  basic 
functional  flows  reflecting  common  functional  requirements  for  each  of 
several  major  weapon  systems  (c.g.,  aircralt,  ships,  command  and  control 
systems).  Further  breakdown  for  type's  (e.g.,  fighters)  would  also  be 
useful.  Ibis  would  alleviate  a major  work  effort  that  applies  from  new 
program  concept  definition  and  early  evaluation  of  re’ated  problem  areas, 
and  carries  throughout  design,  development,  test  and  evaluation.  Access 
to  such  a baseline  would  make  feasible  a very  thorough  review  and  cheek- 
off  of  concept  implications  for  HFl.,  even  f rom  early  summaries  of  pre- 
liminary operating  requirements.  Detailed  development  of  such  information 
is  desirable.  tAihS  has  the  capability  to  accept  and  process  such  data, 
once  developed. 

Secondly,  it  would  1.  desirable  to  initiate  a tabulation  of  commentary, 
problems  and  , i I L • i r 1 ve  sol ut ions  . • latcd  to  each  iunctional  requirement . 
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This  would  provide  invaluable  information  for  the  HFE  analyst  in  making 
trade-offs  and  decisions  in  preliminary  functions  allocations.  Initiation 
and  continuation  of  such  information  is  desirable.  A format  such  as  was 
illustrated  in  Figure  2.2-14  could  be  used  for  this  purpose. 

Thirdly,  the  appropriate  definition,  management,  organization  and  integra- 
tion of  task  data  is  a continuing  quandary;  a data  system  with  data  bank 
is  needed,  and  improvements  in  technological  data  comparability  and  utility 
will  also  be  a continuing  requirement.  in  lieu  of  setting  predictive 
criteria,  present  methods  are  to  assimilate  elements  of  empirical  data  to 
establish  an  accumulated  prediction  of  ability  to  meet  an  external  criteria. 
This  condition  will  likely  continue  for  some  time.  Much  of  the  available 
HFE  data  is  not  directly  comparable,  is  frequently  incompatible  and  is  often 
contradictory.  Even  with  a common  data  element  that  could  be  applied 
throughout  a system  mission  analysis  (such  as  human  reliability)  the  com- 
parability of  concepts  is  difficult  to  establish  for  such  events  as  prob- 
ability of  target  acquisition  versus  probability  of  correctly  selecting  a 
routine  communication  channel.  Even  if  comparable,  performance  constraints 
that  dictate  task  criteria  are  quite  variable  - dictated  by  mission  opera- 
tions, mission  phases  and  the  criticality  of  operation.  (For  example, 
task  tolerances  and  associated  criteria  are  extremely  broad  during  routine 
cruise  flight,  and  conversely  are  extremely  narrow  during  landing.) 

Relevance  of  criteria  are  as  variable,  with  such  distinctive  requirements 
as  physical  size  and  strength,  skill  levels,  vision  characteristics  and 
many  others.  An  information  system  concept  for  HFE  data  is  needed;  given 
this  concept,  CAFES  data  management  capability  could  be  used. 

Fourth,  equipment  variables  effecting  task  performance  capabilities  impact 
the  HFE  process  in  providing  for  effective  crew  performance  in  many  ways. 

Few  equipments  are  identical,  so  that  each  similar  piece  may  satisfy 
common,  similar  and  unique  functional  requirements.  Physical  character- 
istics also  differ,  with  three  variations  of  consequence:  (a)  the  physical 

volume,  weight  and  cost  parameters;  (b)  the  physical  man-equipment  inter- 
face parameters;  and  (c)  interlace  operat ions-workload  parameters  such 
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as  - Che  types  of  periormance  involved;  task  performance  steps,  repetitious, 
qualifications  and  time;  and  task  criticality  to  the  system  mission.  Early 
initiation  of  a data  concept  and  data  tabulation  is  recommended. 

Fifth,  numerous  design  constraints  are  imposed  in  merging  requirements  for 
operations,  crew  performance,  physical  crew  station  volume,  physical  rela- 
tionships of  crew  access  and  anthropometric  needs  versus  the  crew  station 
layout,  and  equipment  characteristics.  Some  such  constraints  are  contra- 
dictory, such  as  the  requirement  for  28-inch  forward  panel  viewing  distance 
versus  30-inch  clearance  for  ejection  seats.  Additional  Integration  methods 
are  desirable  that  would  enhance  the  access  to  and  synthesis  of  data  and 
constraints  from  various  sources,  and  would  also  enhance  the  transition  of 
such  information  into  the  most  generally  suitable  design  concepts. 

Sixth,  elements  of  the  activities  in  developing  requirements  for  manning, 
training,  and  publications  could  benefit  more  directly  and  extensively 

from  tlFE  data.  This  could  be  accomplished  if  progressive  definition  of 

5 

' HFE  analyses  and  data  either  provided  direct  visibility  of  data  relevant 

to  their  needs,  or  permitted  ready  extrapolation  as  required.  Many 
1 interactive  technology  needs  are  indicated  in  present  developments  of 

Specific  Behavioral  Objectives  and  Instructional  System  Design,  e.g.,  in 
detailed  task  data,  in  relative  skills  and  In  number  of  crewmen.  More 
definitive  efforts  to  enhance  the  data  transfer  and  utility  for  this 
intertechnology  interface  is  desirable. 

) 

2.  2.  2.  2 Task-Equipment  Data  Requirements  and  Criterion  Considerations 

General  ultimate  criteria  for  task  performance  by  crewmen  is  in  the  form 
of  successful,  sustained  use  of  equipment  for  effective  system  performance. 
However,  criterion  parameters  for  effective  performance  will  fluctuate 
with  the  mission  phase,  precluding  a simplistic  overall  criteria.  For 
example,  criterion  elements  for  aircraft  systems  performance  during  land- 
ing ore  dramatically  different  from  the  criteria  applied  during  weapon 
delivery.  in  either  case,  the  criteria  are  established  by  the  mission 
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phase  and  are  unique  in  setting  the  performance  objectives  for  selected 
man-equipment  combinations  applicable  to  the  phase.  In  other  words, 
tlie  true  criteria  for  task  performance  are  established  by  the  operational 
context  and  criticality  for  performance.  Performance  quality  and  emphasis 
will  fluctuate  with  selected  critical  operations  that  are  phase  related. 
Accordingly,  with  today's  HFE  state-of-art , both  qualitative  and  quantita- 
tive data  considerations  are  involved.  The  related  data  problem  thus 
becomes  one  of  developing  a concept  for  effective  HFE  use  of  both  data 
types. 

in  general,  the  information  required  to  perform  human  factors  engineering 
analysis  includes: 

o Human  performance  data, 

o Equipment  characteristics  and  performance  data, 

o Specifications  and  standards  to  be  applied. 

In  addition  to  availability  of  such  data,  improved  provisions  are  required 
for  the  storage  and  retrieval  of  pertinent  data  in  order  to  minimize  the 
reaction  time  for  human  factors  analysts  to  provide  trade-off  results  or 
design  information  to  subsystem  designers.  While  the  crewman  is  a vital 
part  of  the  subsystem,  related  design  data  must  precede  the  finalizing  of 
the  configuration  and  structure  of  the  vehicle. 

Ultimately,  the  task  information  on  human  performance  should  include: 
o Nominal  task  performance  data, 

o Effects  of  operating  conditions  on  performance, 
o Differential  performance  characteristics, 

o Applicable  standards  and  specif  i>  tt'ons. 

Nominal  task  performance  data  are  needed  to  define  the  overall  capability 
of  a crewman  to  perform  a specified  task.  Once  the  question  of  task 
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perlormanee  capability  has  been  settled,  it  is  then  necessary  to  determine 
whether  the  performance  is  within  time  constraints,  and  within  acceptable 
reliability  standards.  Ihe  following  discussion  expands  on  data  needs. 


The  nominal  task  data  involves  consideration  of  at  least  the  following: 

o Performance  time, 

o Accuracy, 

o Reliability 

o Additional  behavior  characteristics 

- Cognition  and  decision  response 
Reaction  time 
Force  generation 

o F.rror  type,  magnitude,  and  frequency. 

The  effects  of  operating  conditions  on  performance  are  also  required. 

This  definition  is  to  detail  the  capability  of  the  crewman  to  complete 
the  required  task  in  a satisfactory  manner.  The  change  in  operating 
conditions  effect  changes  in  priorities  which  may  modify  parameters, 
such  as: 

o Performance  mean  values 
o Performance  variability 
o Group  performance 

o Probabilities  of  successful  completion. 

The  capabilities  of  individuals  may  be  modified  to  some  extent  by  training, 
to  assure  performance  of  specific  tasks  in  a more  satisfactory  manner.  The 
amount  of  change  required  to  alter  performance  is  a function  of  previous 
experience  and  knowledge.  Accordingly,  the  additional  characteristics 
that  might  be  needed  for  each  type  of  task  could  also  include: 

o Entry  level  education  and  skills 
o Special  training  requirements 
o Predictive  performance  measures. 
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Additionally,  relevant  data  from  the  specifications  and  standards  appli- 
cable to  all  human  factors  designs  are  requires  The  central  listing  of 
these  items  will  provide  the  analyst  with  ready  access  to  the  information. 
The  listing  also  provides  a checklist  which  decreases  the  chances  of 
overlooking  pertinent  requirements. 

2. 2. 2. 3 Data  System  Requirements 

A data  system  for  storage  and  retrieval  of  human  factors  engineering 
information  is  needed  for  use  in  the  performance  of  both  manual  and  com- 
puterized HFE  methods.  The  different  stages  of  analysis  may  require 
different  or  varying  level  of  detail.  In  addition,  not  all  areas  of 
required  data  will  have  the  same  depth  of  information  available. 

Both  the  conceptual  framework  and  the  format  of  data  storage  for  ready 
access,  comparisons,  use  and/or  updating  is  an  important  aspect  of  data 
system  utility.  With  the  format  adopted,  the  user  must  be  able  to  readily 
obtain  the  level  of  sufficient  detail  necessary  to  satisfy  his  needs. 
Capabilities  and  limitations  summarizing  the  entire  package  of  information 
on  a given  human  task,  or  equipment  item,  needs  to  be  presented  in  order 
to  prevent  masking  of  subtle  constraints  or  complicating  interaction 
effects.  Where  multivariate  relationships  exist,  it  is  essential  that 
these  items  are  identified  and  present  in  the  stored  data.  Additional 
data  qualifications  that  can  be  relevant  include  such  variables  as: 

o Validity 

o Recency 

o Credibility  (e.g.,  estimates,  calculated,  measured) 

o Accuracy 

o Any  special  qualifiers 

Finally,  it  may  become  necessary  for  the  HFE  analyst  to  retrieve  and 
evaluate  data  from  the  original  data  reference.  Accordingly,  data  should 
be  recorded  as  to  the  date,  author  and  source,  i.e.. 
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o Experimental  literature 
o Field  data 

o Contractor  derived  system  design  data 

o Handbooks,  guides,  and  manuals 

0 Subjective  data  from  expert  opinion. 

In  summary,  tbe  real  requirement  for  present  purposes  is  for  a data  system 
that  provides  for  the  systematic  coding, storage  and  retrieval  of  informa- 
tion. A simple  data  bank  concept  is  unlikely  to  be  adequate.  The  system 
employed  for  storing  data  must  be  organized  to  permit  ready  access  to  any 
individual  data  element  as  required  for  review  and  use  as  entered,  or  for 
data  entry  and  updating.  Table  2.2-1  presents  a preliminary  tabulation 
ot  the  types,  formats  and  trade-off  factors  to  be  involved  in  development 

01  the  data  system. 


2. 2.2.4  Data  System  Applications  Concept 

Conceptually,  the  pragmatic  problem  for  the  HFE  analyst  is  in  identifying 
and  appropriately  integrating  both  the  qualitative  information  and  the 
quantitative  data  which  is  minimal  and  sufficient  to  predict  or  appraise 
effectiveness  of  task  performance  relative  to  system  requirements. 
Numerous  approaches  could  be  applied  to  resolving  this  problem.  However, 
only  one  will  be  expanded  here  in  terms  of  present  purposes  to  develop  a 
"single  thread"  process  for  HFE  analyses  and  CAFES  for  applications. 
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Two  major  constructs  can  be  interrelated  into  one  approach:  to  track  and 
correlate  mission  requirements,  constraints,  tradeoffs  influencing  task 
performance  on  the  one  hand, and  to  tabulate  and  use  equipment  related 
tasks  and  performance  data  on  the  other  hand.  The  first  construct  is 
functional  requirements  oriented  and  assumes  that  basic  and  detailed 
functional  flows  are  developed  or  will  become  available  for  each  system 
(e.g.,  aircraft)  that  might  be  of  concern.  The  second  construct  is 
equipment  oriented  and  involves  the  storage  and  use  of  task  performance 
requirements  and  data  as  related  to  given  crew  station  equipment. 
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Data  requirements 

A.  Data  Types 

1.  Effect  of  operational  conditions  on  task  performance 

a.  Task  requirement/tolerance  changes  - accuracy,  timeliness, 
probabil ity 

b.  Changes  in  behavior  effects  of  stress  parameters 

1)  Performance  variability 

2)  Performance  mean  values 

3)  Group  performance 

4)  Probability  of  successful  completion. 

2.  Differential  performance  characteristics  - key  task  related 

a.  Skills,  skill  level 

b.  Educational  level 

c.  Special  training 

d.  Other  correlates  predictive  of  performance 

3.  MIL-STD  or  other  task/performance/equipment  guideline 

a.  Data  coded  for  compliance  with  standard 

b.  Standard's  data  retrievable 

4.  Nominal  task  performance  data  — task  elements 

a.  Speed 

b.  Accuracy 

c.  Reliability 

d.  Additional  behavioral  capabilities  (cognition/decision 
responses,  reaction  time,  force  gen.,  etc.) 

e.  Error  type,  magnitude,  frequency 

5.  Equipment  data 

a.  Performance  characteristics 

b.  Operating  requirements  and  description 

B.  Data  Format 

1.  Capacity  to  call  up  the  level  of  detail  required 

2.  Total  task  information  presented  (prevents  masking  interaction  effects) 

3.  Capability  for  multivariate  relationships  to  be  presented  or  displayed 

4.  User  organizational  freedom — access  requirements  and  output  flexibility 

5.  Multi-access  schema 

6.  Operational  terms  employed  to  facilitate  data  retrieval 

7.  Updating  must  be  simple  to  enhance  appropriate  task-equipment  access 
and  data  expansion 

8.  Rapid  hard  copy  (user  option) 

9.  Summary  of  data  at  a prescribed  level  be  available 

C . Data  Sources  and  Qualifications  (Retrieval  Source,  Date,  Author  to  Be  — 
Displayed  with  Data) 

1.  Experimental  literature 

2.  Field  data 

3.  System  design  phase  - contractor  derived 

4.  Handbooks,  guides,  manuals 

5.  Expert  opinion  - subjective  data 

D.  Data  Store  Development 

1.  Establish  overall  framework  to  permit  systematic  growth 

2.  Optimize  and  encourage  d ta  availability 
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In  the  first  construct,  the  ultimate  level  of  detail  developed  by  the 
functional  flows  or  other  analysis  techniques  would  be  extended  to  reflect 
experience,  unsatisfactory  reports  and  trade-off  data  much  as  previously 
illustrated  by  Figure  2.2-14,  and  repeated  here  as  Figure  2.2-17  for 
reader  convenience.  Characteristics  of  relevant  variables  concerning  the 
man-equipment  interface  and  operator  performance  features  were  tabulated 
in  Table  2.1-3.  That  information  is  also  repeated  in  Table  2.2-2  for  con- 
venience. At  a minimum,  this  approach  would  facilitate  maximum  use  of 
available  information  and  data  by  the  analyst  for  readier  appraisal  of 
response  characteristics  that  could  influence  performance,  e.g.,  response 
type,  difficulty,  consistency,  peculiarities,  variability,  range  and  impact 
on  mission  performance.  It  could  also  facilitate  more  systematic  identi- 
fication of  data  gaps  and  appraisal  of  both  the  significance  and  consequences 
of  such  gaps. 

An  additional  feature  of  the  construct  is  that  the  level  of  indenture 
would  carry  to  that  level  of  detail  where  specific  requirements  involving 
man-machine  interface  units  are  identifiable,  along  with  candidate  equip- 
ments, task  requirements  and  constraints  or  trade-off  features.  Known 
candidate  control-display  equipments  would  also  be  identified  at  this 
level.  However,  the  construct  would  retain  the  flexibility  to  modify  pre- 
programmed information  in  order  to  better  fit  specific  mission  requirements, 
or  to  incorporate  new  equipment  concepts,  inventions  or  trade-off  informa- 
tion as  relevant  and  desirable.  Accordingly,  the  construct  encompasses 
the  necessary  features  and  adaptability  to  reflect  all  possible  mission 
requirements,  to  incorporate  innovative  solutions,  and  to  retain  assurance 
that  all  requirements  are  suitably  met. 

The  result  is  a concept  that  relates  directly  to  earlier  discussions 
covering  the  analytic  process  from  early  functional  flows  and  will  not  be 
further  expanded  in  this  section.  It  does  not  offer  a straight  forward 
clearly  quantifiable  progression  for  HFE  application.  However,  it  does 
provide  for  the  systematic  recording  of  information  against  the  functional 
flow  indentures.  It  also  provides  for  increased  assurance  that  HFE 
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decisions  take  into  account  both  basic  mission  parameters  and  all  relevant 
task  performance  variables.  In  the  near  term  application  it  will  provide 
an  interim  technological  base  for  improving  the  scope  of  relevant  areas 
covered  by  HFE  efforts  while  the  state-of-art  for  a quantitative  data 
base  is  being  further  refined  and  developed.  It  also  offers  a framework 
for  continuing  incorporation  and  use  of  either  quantitative  information 
that  may  not  be  comparable,  or  qualitative  information  that  may  never  be 
quantifiable. 

The  second  construct  relates  directly  to  the  candidate  man-machine  interface 
equipments  that  are  identifiable  at  the  ultimate  level  of  indenture  in  the 
functional  flows  or  other  analytic  results.  It  accepts  the  notion  that  new 
systems  may  make  extensive  use  of  pre-existing  (traditional)  controls  and 
displays  for  which  tasks  are  defined  and  task  data  can  be  obtained. 
Alternatively,  the  system  may  use  new  control  and  display  concepts  which 
have  been  developed  and  confirmed  sufficiently  for  data  to  be  available. 

The  point  is  that  few,  if  any,  new  systems  will  involve  radical  and 
revolutionary  changes  in  the  total  state-of-art  that  are  so  dramatic  as 
to  invalidate  all  prior  functional  requirements,  associated  equipment  and 
data.  Accordingly,  task  performance  requirements  and  data  can  be  tabulated 
and  recorded  for  each  item  that  is  identified  from  the  functional  flows. 

In  turn,  pre-existing  data  on  equipment-related  tasks  can  be  retrieved  and 
used  as  each  becomes  a candidate  in  the  functions-allocation  process. 
Similarly,  data  on  hardware  characteristics  and  performance  can  be  stored 
for  retrieval  and  use  as  required  (e.g.,  weight,  volume,  interface  signals, 
display-control  features) . 

Accordingly,  the  second  construct  is  oriented  toward  man-machine  interface 
equipment,  i.e.,  controls  and  displays.  This  construct  has  evolved  over 
several  applications  developments,  with  the  most  recent  and  extensive 
investigations  sponsored  by  the  Boeing  Commercial  Airplane  Company. 

Titled  Cockpit  Information  Storage  and  Management  System  (CISMS,  Reference 
42),  the  present  development  is  concerned  specifically  with  the  aircrew 
cockpit  and  associated  hardware.  It  provides  for  definitive  hardware 
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specification  and  for  data  storage  and  retrieval  covering  variations  in 
operation  according  to  flight  phases,  flight  requirements,  flight  functions 
subsystem  elements,  and  control-display  functions.  With  the  hardware  items 
specifically  identified,  additional  information  is  included  that  covers: 
functional  capabilities  of  the  hardware;  interaction  requirements  between 
the  operator  and  equipment;  task  related  information  (e.g.,  time,  constraints, 
performance  reliabi li ty );  and  such  physical  characteristics  as  volume,  weight 
and  power  input  requirements.  In  general,  data  updating  can  be  accomplished 
directly  for  the  equipment  for  which  new  data  applies.  An  example  of  the 
overall  construct  is  illustrated  in  Figure  2.2-18  and  the  detailed  equipment 
areas  are  shown  in  Figure  2.2-19. 

Application  of  the  overall  data  system  concept  would  be  to  retrieve  and 
adapt  the  functional  requirements  flows  of  the  first  construct,  through 
the  crew  station  equipment  candidates.  Candidates  could  be  identified  by 
the  HFE  analyst  at  this  point,  or  he  could  retrieve  and  review  the  equipment 
data  of  the  second  construct  before  making  such  selections.  In  either  case 
he  has  ready  access  to  all  relevant  data  for  making  initial  functions 
allocations  and  progressing  through  the  HFE  activities  described  in  the 
first  section  of  this  report. 

Such  concepts  and  data  as  are  described  above  apply  for  botli  manual  HFE 
methods  and  those  methods  augmented  by  computer  aids.  In  both  instances, 
the  intent  and  type  of  effort  are  essentially  the  same,  but  the  extent  of 
effort  required  and  level  of  depth  supporting  the  results  will  differ 
markedly.  The  difference  is  that  the  manual  process  will  tend  to  be  far 
less  comprehensive  without  a rather  extensive  baseline  being  made  available. 
Similarly,  detailed  or  iterative  calculations  will  be  less  likely.  On  the 
other  hand,  development  of  such  a baseline  does  allow  for  most  effective 
use  of  qualitative  information  and  of  professional  skill,  experience  and 
judgment.  Additionally,  in  any  new  application,  the  computer  can  supplement 
the  process  by  first  retrieving,  organizing  and  presenting  information  for 
the  HFE  analyst  to  review,  critique  and  modify;  secondly,  reorganizing  the 
Information  as  instructed;  and  finally  performing  such  calculations  and 
iterative  operations  as  are  required. 
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TASK  PERFORMANCE  DATA  ELEMENTS 

The  task  information  currently  being  used  for  systems  development  and  the 
CAFES  submodel  assessments  are  generally  derived  from  "expert"  knowledge, 
(including  knowledge  of  data  sources),  rather  than  being  drawn  from  a 
storage  bank  of  information.  The  ability  to  further  automate  task  alloca- 
tion and  workload  analysis  requires  the  inclusion  of  stored  information 
about  human  movement,  operation,  manipulation,  cognition,  processing  and 
reactive  times  as  well  as  efficiency,  and  effectiveness  or  reliability  of 
the  above  definitions. 

The  operator,  in  his  primary  role  as  an  information  processor,  decision 
maker  and  controller,  will  be  working  in  conjunction  with  specific  items 
of  equipment.  Accordingly,  to  a large  extent  the  type  of  data  and  storage 
requirement  can  be  tied  to  specific  pieces  of  equipment.  This  is  readily 
compatible  with  the  computer  storage  and  retrieval  programs.  Since 
specific  subsystems  and  hardware  items  are  identified  in  a synthesized 
system  concept  from  initial  functions  allocations,  the  associated  data 
(describing  actions  required  by  the  operator  to  effect  desired  requirements) 
can  be  available  for  f unctions-tasks  allocation,  task  timeline  development 
and  workload  analyses. 

The  task  data  tied  to  a specific  mission  requirement,  subsystem  or  piece 
of  equipment  can  include: 

1.  function(s)  performed  or  augmented  by  use  of  equipment, 

2.  function  criticality, 

3.  actions  required,  controls  to  be  actuated,  or  manipulations  to  be 
performed, 

4.  type  of  information,  displays  to  be  viewed  or  manner  of  information 
feedback  provided  for  each  manipulation, 

5.  more  commonly  used  general  location  and/or  orientation  of  equipment, 

to  define  the  degree  of  difficulty  associated  with  viewing  and  reaching 
of  the  controls  and/or  displays, 

6.  channels  of  activity  necessary  to  absorb  and/or  acknowledge  information 
displayed,  as  well  as  to  input  control  actions. 
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7.  type  and  time  duration  of  required  activities, 

8.  typical  response  characteristics:  frequency,  range,  consistency, 

9.  interdependency  of  equipment  functioning,  with  associated  components 
and  priorities  of  operation  among  equipment  functions. 


Other  task  data  characteristics  of  interest  include  a measure  of  the 
adequacy,  rapidity  and  accuracy  versus  type  of  operation  (,e.g.,  a measure 
of  effectiveness,  or  of  probability  of  successful  completion  of  the 
activity  within  a specified  time  period).  These  types  of  data  contribute 
to  evaluation  of  the  variabilities  between  crewstation  configurations  and 
the  effects  of  varying  combinations  and  arrangements  of  controls  and  displays 
However,  there  are  limitations  and  precautions  to  be  observed  in  establishing 
task  data  characteristics  that  are  commonly  and  directly  comparable  for  all 
operations.  Much  of  the  data  that  are  available  are  useable  in  the  context 
of  being  qualified  and  applied  with  sound  professional  expertise,  but 
frequently  lack  the  general  utility  that  would  accrue  with  the  ability  to 
perform  more  complex  mathematical  operations,  e.g.  additive  or  multiplicative 
uses.  Considerable  progress  has  been  made  in  such  data  areas  as  human 
performance  reliability,  task  performance  time  and  accuracy.  These  data  can 
be  applied  meaningfully  to  permit  reasonable  comparisons  of  predicted 
effectiveness  between  system  concepts,  and  to  produce  preliminary  appraisals 
for  a given  system  concept.  As  this  data  base  is  refined  and  improved 
through  use  and  validation,  significant  improvements  will  accrue  in  both  the 
quality  of  predictions  and  ultimate  operational  results. 

CREWSTATION  HARDWARE  IMPLEMENTATION-LAYOUT  DATA 

The  development  of  functional  flow  block  diagrams  to  the  lower  levels  of 
indenture  begins  to  isolate  candidate  equipment  components  for  various 
phases  of  the  mission.  The  identification  of  candidate  equipment  by  phase 
then  leads  to  an  evaluation  across  the  entire  mission  and  a trade-off 
as  to  the  pragmatic  arrangement  which  appears  most  feasible. 


The  information  specifically  concerned  with  the  equipment,  in  addition 
function(s)  capable  of  being  performed,  include  the  following  physical 
charac  terist ics: 
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o dimensions  of  package 

o display/control  types,  features,  quantities 

o display/cont rol  dimensions 

o force  required  for  manipulation 

o type  of  movements  necessary 

o means  to  verify  control  position/actuation 

o power  input  type/quantity 

o related  equipment  necessary  for  operation,  input  signal  or  output 
processing. 

« 

« Such  information  is  definable  for  storage  and  retrieval  in  an  information 

system.  Prior  layout  concepts,  trade-off  qualifications  and  criticalities, 

* 

and  such  considerations  as  representative  frequency  of  use  are  definable 
for  storage  and  retrieval.  Additional  considerations  such  as  unique 
requirements  for  a given  display  or  control  related  to  mission  phase  (or 
peculiar  task  data,  characteristics  or  constraints  related  to  a given  item) 
^ could  also  be  stored  for  easier  use  and  retrieval.  In  short,  there  is  a 


strong  case  for  an  information  system  that  organizes,  stores  and  makes 
available  such  data,  with  appropriate  qualifications,  for  readier  use. 


2.3 


COMPUTER  AIDED  FUNCTION-ALLOCATION  EVALUATION  SYSTEM  (CAFES) 
CONCEPT  SUMMARY,  CHARACTERISTICS,  OUTPUTS  AND  USES 


2.3.1  General 

CAFES  development  is  intended  to  be  used  to  support,  enhance  and  expedite 
the  HFE  processes  described  in  preceding  sections.  The  objective  is  to 
provide  for  improved  and  timely  results  and  more  effective  use  of  such 
results  in  management  decision  making  during  a system  development  program. 
This  objective  is  to  be  accomplished  by  computer  technology  to  facilitate 
organization,  processing  and  use  of  data,  and  to  assure  early,  systematic 
and  comprehensive  treatment  of  all  crew  related  parameters  that  need  to 
be  considered  in  system  programs.  Representative  system  areas  where  such 
applications  are  expected  to  be  beneficial  include: 

1.  Improved  development,  evaluation  and  confirmation  of  crew  station 
configurations 

2.  Improved  weapon  system  performance  through  improved  crew  performance 

3.  Higher  probability  of  mission  success 

4.  Improved  manpower  utilization 

5.  Reduced  training  costs 

6.  Improved  safety  through  fewer  errors  and  accidents  in  system  operations 

7.  Improved  crew  systems  performance  in  airborne  systems 

CAFES  use  for  HFE  efforts  during  system  development  will  offer  many  tech- 
nological advantages  for  the  analyst.  It  will  help  to  develop,  record 
and  provide  consistent  and  comprehensive  analysis  data  relating  to  present 
and  future  systems  developments.  It  will  provide  a record  of  on-going 
development  decisions  and  rationale  during  a given  program,  i.e.,  a 
recording  of  crew  related  information  for  a given  system,  from  early 
requirements  analyses  through  design,  development,  test  and  evaluation, 
and  training  systems  development.  It  will  facilitate  data  access,  inte- 
gration, interpretation  and  use  in  program  support  activities.  It  will 
enhance  ability  Lo  make  effective  judgements  while  offloading  routine, 
elementary  and  tedious  analytic  operations.  It  will  provide  a tool  for 
evaluating  effectiveness  of  decisions  prior  to  implementation.  Finally, 
it  will  help  to  identify  data  gaps  and  needed  man-machine  research  to 
support  development. 
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2.3.1  (Continued) 

In  effect,  CAFES  provides  computer  techniques  to  structure,  control  and 
evaluate  crew  systems  aspects  of  a developing  system.  It  provides  for 
maximum  use  of  data  from  experience,  research  and  other  programs  to  provide 
early  analytic  results.  It  also  provides  for  improved  continuity  in  the 
parametric  trade-offs  of  man-machine  interfaces  necessary  for  most  effective 
crew  related  provisions  in  a comprehensive  system  development.  Most 
specifically,  CAFES  extends  the  use  of  computer  technology  for  HFE  applica- 
tion through: 

o Application  of  computer  techniques  to  assist  in  requirements  defini- 
tion, function  allocation,  workload  evaluation,  preliminary  crew 
station  design,  and  evaluation  and  other  human  engineering  trade- 
off studies  and  activities  which  have  been  accomplished  by  manual 
means. 

o Integration  of  the  computer  methods  to  provide  efficient  and  com- 
prehensive capability  for  more  extensive  analysis  of  man-machine 
interface  interactions,  to  provide  much  of  the  needed  human  factors 
data  for  systems  development,  and  to  provide  critical  trade-decision 
data  as  needed. 

However,  CAFES  cannot  work  effectively  without  guidance  based  on  the 
expertise,  skill,  and  professional  judgements  of  a knowledgeable  human 
factors  engineer.  As  in  more  traditional  methods,  he  must  make  numerous 
decisions  based  on  interpretation  of  system  requirements,  specifications 
and  applications  of  qualitative  as  well  as  quantitative  information.  This 
will  continue  to  be  the  case  with  the  type  of  HFE  information  and  data 
used  in  the  analytic  process,  and  the  type  of  trade-off  decisions  required 
(e.g.,  relating  to  crew  size,  display  requirements  and  features,  life 
support  variations  and  resolution  of  conflicting  data).  The  computerized 
models  can  only  assist  the  process  by  retrieving,  processing,  organizing 
and/or  presenting  data  as  required.  They  can  also  be  used  to  evaluate 
the  system  impact  of  alternative  trade-off  decisions. 
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2.3.1  (Continued) 

Since  CAFES  require*  involvement  of  the  HFE  analyst,  effective  interface 
provisions  are  continually  emphasized.  English  language  formatting  is 
used  for  easier  use  and  interpretation.  Additionally,  model  concept 
development  is  now  to  the  point  where  added  attention  to  simplified 
input-output  formatting  is  timely,  to  minimize  efforts  to  input, 
access  and  use  the  models.  One  of  the  goals  for  the  present  is  to  clarify 
areas  where  related  refinements  are  desirable. 

In  summary,  the  CAFES  concept  development  and  application  is  based  on  a 
synthesis  of  (1)  crew  system  methodologies,  (2)  applicable  HFE  data 
derived  from  a diverse  set  of  sources,  (3)  management  by  the  HFE  analyst 
as  the  control  element,  evaluator  and  decision-maker  during  CAFES  opera- 
tion, and  (4)  a computerized  data  management  system  coupled  with  models 
supporting  typical  processes  to  store,  retrieve  and  manipulate  data, 
procedures  and  programs. 


2.3.2 


Submodel  Definition 


For  the  purpose  of  permitting  comparison  of  various  CAFES  operations  with 
the  baseline  methodological  developments  of. earlier  discussions,  summaries 
of  the  various  submodels  follow.  The  summaries  provide  a CAFES  orientation 
for  the  reader  who  is  not  familiar  with  the  program,  and  provide  highlights 
of  relevant  features  correlated  with  the  baseline  process  for  the  reader 
who  is  familiar  with  the  program.  Summaries  are  heavily  based  on 
abstracting  and  organizing  data  from  published  documentation.  More 
detailed  descriptions  are  available  in  technical  reports  published  during 
development  of  the  submodels.  These  reports  include  references  1 through 
18  for  the  Crewstation  Geometry  Evaluation  (CGE)  submodel,  and  19  through 
29  for  the  Data  Management  System  (DMS),  the  Function  Allocation  Model 
(FAM) , the  Workload  Assessment  Model  (WAM) , the  Computer  Aided  Design  of 
Crew  Stations  Model  (CAD),  and  the  Human  Operator  Simulator  (HOS). 

Other  references  (30  through  46)  contain  background  information  relevant 
to  submodel  development  or  to  related  methods,  concepts  and  applications. 

The  computer  aids  are  a set  of  submodels  working  in  conjunction  with  a 
data-inf ormat ion  management  system.  Each  submodel  may  be  used  individually 
or  in  combination  with  one  or  more  of  the  other  submodels,  depending  upon 
the  requirements  for  data  and  analysis  at  any  point  in  the  research, 
development,  test  and  evaluation  cycle.  The  modular  construction  of 
CAFES  will  provide  flexibility  for  inclusion  of  the  nyriad  of  parameters 
that  may  have  to  be  integrated  for  meaningful  definition  and  evaluation 
of  the  human's  role  in  a system  development. 

Hie  CAFES  submodels  are  identified  by  name  below: 

1.  Data  Management  System  (DMS) 

2.  Function  Allocation  Model  (FAM) 

3.  Workload  Assessment  Model  (WAM) 

4.  Computer-Aided  Crew  Station  Design  Model  (CAD) 

5.  Crew  Station  Geometry  Evaluation  Model  (CGE) 

6.  Human  Operator  Simulation  Model  (HOS) 
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2.3.2  (Continued) 

Each  of  these  CAFE3  components  is  described  in  later  sections,  together 
with  their  development  status,  inputs,  outputs,  general  purpose,  and 
utility.  Figure  2.3-1  together  with  Tables  2.3-1  and  -2  provide  an 
introductory  overview  of  these  subjects. 
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The  design  of  the  system  provides  the  user  with  necessary  computer  program 
visibility  and  essential  elements  of  control  for  effective  use  and  manage- 
ment. Several  related  objectives  are  involved  in  the  intent  to  provide  a 
tool  useable  by  the  human  factors  engineering  community.  These  objectives 
are  to  provide  for: 

1.  Broad  applicability  in  producing  data  for  human  factors  engineering 
across  the  full  spectrum  of  man-machine  systems,  research  and  develop- 
ment activities;  and  operational  problem  solving.  Tn  addition  to 
system  design  and  operations,  CAFES  will  also  be  applicable  to  train- 
ing, maintenance,  job-aids,  and  other  functional  regimes  where  human 
performance  is  critical  to  system  effectiveness.  For  example,  CAFES 
can  be  applied  to  training  in  several  respects: 

o Definition  of  training  requirements  for  crews  of  a new  system 

(e.g.,  task  procedures,  proficiency  levels,  task  allocations,  etc.), 
o Man-machine  allocation  within  a training  system  (e.g.,  trade 

between  instruction  by  humans  and  machine-assisted  training  aids), 
o Workload  analysis  for  training  procedure  development  (e.g.,  for 
degraded  mode  training). 

o Add  to  design  of  training  devices  (e.g.,  instructor  consoles), 
o Evaluation  of  training  programs  by  comparison  oftrained  skills 
versus  required  skills,  trained  procedures  versus  optimum  pro- 
cedures, etc. 

2.  Visibility  and  traceability  for  quick  identification  of  the  factors 
having  greatest  effect  on  system  performance  and  underlying  assump- 
tions which  heavily  influence  CAFES  estimates  of  system  performance. 
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1 AliU1.  2.1-1  CAFES  COMPUTER  AIDS 


NAME 

Data  Management  System 
( 1)MS  ) 


Function  Allocation  Model 
(FAM) 


Workload  Assessment  Model 
(WAM) 


Computer  Aided  Crewstation 
Design  Model 

(CAD) 


I 

| Crewstation  Geometry 

! Evaluation  Model 

, (CGE) 

f Human  Operator  Simulation 

(HOS) 


PURPOSE 

Provide  a highly  flexible  data  storage/ 
retrieval  system  for  the  full  range  of  HFE  data 
needs;  assure  ready  orderly  use  and  updating. 

Process/ rest  man-machine  task  allocation 
solution  sets  for  each  alternative  equipment 
selections  per  mission  requirements. 

Identify  and  evaluate  tasks,  procedures, 
frequency  and  time  of  display/control  usage 
on  composite  mission  profiles  to  verify  over- 
all feasibility  of  specific  man-machine 
comb inat ions . 

Assist  in  preliminary  crewstation  configura- 
tion layout  - use  FAM  and  WAM  results  to 
systematically  structure  station  configuration 
according  to  design  requirements/constraints 
derived  by  FAM  and  WAM. 

Identify  potential  physical  incompatibilities 
between  the  proposed  crewstation  and  standard 
anthropometric  and  ergometric  data. 

Provide  a generalized  computer-driver  model 
of  a human  being  in  a goal-oriented  task 
processing  environment. 
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TABLK  2.3-2: 


CAFES  CAPABILITIES 


FUNCTION  ALLOCATION 

o 

(FAM) 

o 

o 

WO  RK  L OAD  AS  S E S S M EN  T 

o 

(WAM) 

o 

o 

COMPUTED  AIDED  CREWSTATT ON  o 

DESIGN 

o 

(CAD) 


CREWSTATION  GEOMETRY  o 

EVALUATION 

(COE)  o 

HUMAN  OPERATOR  SIMULATION  o 

(HOS)  o 


BEST  CREW  SIZE 

BEST  AUTOMATION  LEVEL 

OPTIMUM  TASK  ALLOCATION 

VERIFICATION  OF  ALLOCATIONS 
DETAILED  PROCEDURE  ANALYSES 
OPTIMUM  CREW  STATION  DESIGN 

FEASIBLE  STATION  LAYOUTS 

SENSITIVITY  TO  REQUIREMENTS, 
CONSTRAINTS,  CRITERIA 

VERIFICATION  OF  DETAILED 
CONFIGURATIONS 

TASK  TIME  ESTIMATES 

HUMAN  PERFORMANCE  ESTIMATES 

SENSITIVITY  TO  BEHAVIORAL  FACTORS, 
OPERATING  ENVIRONMENTS,  ETC. 
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2.3.2 

3.  Consistency  with  state  of  the  art  in  human  factors  methodology  and 
data  but  with  growth  potential  to  incorporate  new  techniques  and 
improved  data. 

4.  Flexibility  to  evaluate  impact  of  changes  in  analysis  conditions;  for 
example,  degraded  modes  of  operation,  mission  scenario  changes,  etc. 

5.  Capability  for  human  factors  personnel  to  interact  with  CAFES  computer 
systems  such  that  prolessiotial  judgement  can  be  aided  by  the 
computed  results. 

6.  Capability  for  quick  nummary  results  for  studies  of  "hot"  problems 
requiring  quick  turnaround,  or  can  be  employed  in  long-term,  in-depth 
studies  involving  extensive  detail  and  integration. 

The  application  of  the  CAFES  submodels  in  human  engineering  will  be  dis- 
cussed under  the  section  !'(>*■  each.  Ilovevc  ',  the  greatest  utility  ol  t.Al  i.S  is  in 
the  integrated  use  of  submodels  for  interactive  use  of  information  or  to 
produce  any  specific  output  data  and  analysis  required  during  new  systems 
development.  An  example  of  model  relationships  is  illustrated  in  Figure 
2.3-2;  interactive  application  of  these  models  can  help  to  produce  all 
the  various  CAFES  results  that  were  summarized  in  Figure  2.3-1. 


Primary  outputs  of  each  model  are  shown  in  Figure  2.3-2.  Major  feedback 
loops  are  also  indicated.  For  example,  the  workload  analysis  by  the  Work- 
load Assessment  Model  may  suggest  a re-exercise  of  the  Function  Allocation 
Model  to  evaluate  different  allocation  versions,  and  outputs  from  Crew- 
station  Geometry  Evaluation  Model  may  suggest  a change  in  basic  configura- 
tion to  be  run  on  the  Computer  Aided  Crewstation  Design  Model.  Consequently, 

- the  integrated  c.ip.ib  i 1 i I.  v ol  the  CAFES  method  will  be  fully  realized  when 

• ill  submodels  are  completed  and  i n I e r re  I a Led . 
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CAFES  can  be  applied  at  alternative  levels  of  detail,  and  would  normally 
be  applied  iteratively  tnroughout  the  system  development  cycle.  System 
detail  is  usually  sketchy  during  early  concept  formulation,  but  CAFES 
can  still  be  applied  at  a gross  level  or,  with  numerous  assumptions,  at  a 
detailed  level.  As  system  development  progresses,  the  ratio  of  system  detail 
to  system  assumptions  improves  considerably  and  CAFES  analysis  can  be  carried 
to  much  greater  detail.  Operation  of  the  various  CAFES  submodels  is  not 
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2.3.2  (Continued) 

constrained  by  level  of  detail.  The  Function  Allocation  Model,  the  Work- 
load Assessment  Model,  etc.,  can  operate  at  any  level  throughout  the  range 
from  top  level  functions  to  very  specific  subtasks.  The  second  aspect  of 
CAFES  applications,  iterative  operations,  refers  to  the  interactive  nature 
of  the  different  submodels,  and  the  potential  for  analysis  refinement  through 
multiple  runs  of  each  submodel  based  on  dynamic  changes  in  results  from  the 
other  CAFES  submodels.  Although  most  effective  use  of  CAFES  will  include 
the  sequential  application  of  all  submodels,  each  of  the  submodels  may  also 
be  used  independently,  and  provide  data  specifically  for  a given  problem. 

Continued  analysis  and  development  of  methods  for  applying  CAFES  to  Navy 
systems  development  is  required  to  assure  an  evolution  of  maximum  practicality 
and  useability.  CAFES  applications  to  various  Navy  missions,  systems, 
and  development  activities  are  illustrated  in  Figure  2.3-3.  The  general 
flow  for  the  CAFES  application  analysis  is  illustrated  in  Figure  2.3-4. 

For  any  system,  the  types  of  data  and  analyses  that  can  be  produced  or 
supported  by  CAFES  include: 

1.  Man-machine  function  allocation. 

2.  Mission  task  analysis. 

3.  Information  requirements. 

4.  Control-display  listing. 

5.  Crew-loading  timeline  assessment. 

6.  Crewstation  configuration  requirements/constraints  listing. 

7.  Crewstation  geometry  evaluation. 

8.  Operational  procedures  specification/evaluation. 

9.  Operator/system  performance. 

10.  Crewstation  design-related  trade-off  analysis. 

Upon  completion  of  CAFES  development  a user-oriented  capability  will  be 
available  for  systematically  structuring  and  evaluating  those  parameters 
having  a direct  impact  on  crew  systems  operations.  The  information  to  be 
generated  through  CAFES  utilization  will  be  in  context  with  that  of  other 
systems  development  activities  at  equivalent  points  in  the  development 
cycle. 
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FIGURE  2.3-4:  CAFES  APPLICATIONS  ANALYSIS 


'mi* 


2.3.2  (Con l inued) 

Submodels  will  be  applicable  to  human  factors  tasks  throughout  the  develop- 
ment and  operational  cycle  of  Navy  man-machine  systems.  from  early  identi- 
fication of  crew  system  requirements  during  the  conceptual  phase  through 
system  evaluation  during  fleet  operations,  CAFES  will  be  exercised  repeatedly 
to  assist  requirements  analyses,  test  and  systems  design,  procedures  develop- 
ment, and  training  and  maintenance  systems  development. 


Following  discussions  summarize  the  various  models.  In  order  to  provide 
a conceptual  framework  for  present  discussion  while  minimizing  redundancy 
with  data  which  has  been  published,  the  approach  for  the  discussions  was 
to 

o Briefly  summarize  the  submodel  concept 

o Outline  the  requirements  specification 

o Produce  such  commentary  as  are  relevant  and  necessary  to 


Relate  submodel  uses  to  the  baseline  methodology 


developed  earlier 

o Identify  desirable  refinements 

For  more  detailed  information  on  submodel  design,  features  and  operations, 
the  reader  is  referred  to  appropriate  documents  in  the  reference  list. 


2.  3.  3 


Data  Management  System  (DMS) 
General  Concept 


2.3. 3.1 

The  Data  Management  System  (DMS)  provides  two  roles  in  the  CAFES  concept. 

(1)  It  provides  a storage  capability  for  all  1 1 I'll  endeavors , 

encompassing  a variety  of  different  structures,  hierarchy  and  data  forms. 

(2)  It  provides  the  collection  of  instructions  and  routines  to  manipulate 
the  data  for  each  of  the  submodels  and 

(i)  II  provides  the  interfaces  between  the  computer  submodels. 

The  human  factors  engineer  interfaces  with  the  DMS  in  several  ways. 

1.  to  input  new  data 

2.  to  modify  data  in  storage 

3.  to  delete  stored  data 

4.  to  instruct  CAFES  submodel  execution 

5.  to  instruct  report  preparation 

6.  to  receive  data  reports 

The  type  of  information  required  for  the  vast  and  varied  human  factors  task 
requires  an  extensive  storage  system.  Accordingly,  cost  effectiveness  must 
be  considered  for  the  data  entry  taxonomy.  The  system  must  be  flexible  and 
yet  manageable  to  minimize  the  cost  of  inputting,  storing,  and  retrieving  the 
initial  information  as  well  as  minimizing  the  cost  of  the  report  summary 
data  package.  Also,  it  must  provide  for  simple  operations  to  update,  replace, 
modify,  augment  and  otherwise  manipulate  the  data  collection.  In  addition, 
the  data  management  system  must  allow  for  communication  between  the  generater 
of  data  and  the  user  of  the  data,  and  with  the  set  of  computer  submodels 
which  operate  with  the  data. 

The  data  management  system  is  a set  of  instructions  which  work  from  initial 
instructions  from  the  human  factors  analyst  to  compile  and  allocate  data  in 
the  format  necessary  for  direct  data  access  or  for  use  by  each  one  of  the 
CAFES  submodels.  The  results  of  manipulation  by  each  submodel  is  both  pre- 
sented and  stored,  with  the  initial  input  information,  for  retrieval  in 
report  form  at  a later  time.  The  data  are  also  available  for  transformation 
as  input  data  to  another  submodel.  Figure  2.3-5  illustrates  the  interactions 
of  the  various  functions  performed  by  the  data  management  system. 


2.3. 3.2 


Data  Management  System  Requirements  Specification 


This  dual  role  of  user  interface  and  submodel  interface  places  special 
demands  on  the  data  management  system  in  terms  of  .iccommodai  ing  but  ban  easy- 
to-use  data  format  for  the  human  factors  engineer  and  an  efficient  data 
format  for  transferring  data  to  and  from  the  computer  submodels.  Specific 
design  requirements  to  which  the  data  management  system  was  developed  are 
summarized  in  the  following  listing: 

o The  input  and  output  formats  for  the  data  management  system  shall  be 

designed  for  ease  of  use  and  interpretation  by  human  factors  engineers, 
o The  DMS  shall  be  consistent  with  CAFES  objectives  and  shall  be  designed 
for  efficient  interface  with  all  CAFES  submodels, 
o The  DMS  shall  accommodate  all  data  parameters  required  by  all  human 
engineering  methods  - both  computerized  and  manual, 
o The  DMS  shall  provide  options  to  selectively  input  or  output  data  with 
easy-to-use  instructions. 

o The  DMS  shall  provide  flexibility  for  user  specification  of  output 
data  formats. 

o The  DMS  shall  provide  means  for  easy  modification,  addition,  or  dele- 
tion of  data  in  storage. 

o The  DMS  shall  provide  safeguards  for  data  in  storage  such  that  data 
cannot  be  inadvertently  lost  or  destroyed, 
o The  DMS  shall  be  efficient  in  handling  and  storing  both  large  and 

small  amounts  of  data  but  shall  use  economical  storage  means  whenever 
possible. 

o The  detailed  structure  of  the  DMS  shall  be  designed  for  growth  potential 
to  efficiently  accommodate  new  data  parameter^,  and  data  formats  as  they 
become  available  (e.g.:  when  CAFES  submodels  are  added  or  modified), 

o The  DMS  shall  facilitate  high  commonality  of  data  parameters  between 
the  various  submodels  and  shall  be  internally  consistent  in  units, 
constants,  nomenclature,  etc. 

o The  DMS  shall  provide  error  messages  and  diagnostics  for  trouble 


shooting  purposes  and  shall  be  "fail  safe"  by  supplying  standard 
data  for  submodel  execution  in  the  event  a user  fails  to  specify 

yf 


2.3.3.  3 


Data  Management  System  Relationship  to  Baseline  Methodology 


Numerous  candidate  areas  for  DMS  provision  of  data  were  identified  in  the 
section  on  baseline  methodology.  Two  major  distinctions  existed.  The 
first  was  between  that  initial  information  and  data  base  which  was  neces- 
sarv  to  organize  information  prior  to  initiating  application  of  any  of  the 
various  submodels.  The  second  was  that  information  and  data  used  by  each 
submodel.  For  convenience  of  discussion,  the  initial  data  base  will  be 
treated  here.  Information  relevant  to  each  submodel  will  be  discussed 
in  the  appropriate  submodel  discussion. 

Four  major  preparatory  efforts  were  indicated  in  the  baseline  methodology: 
composite  mission  requirements,  functional  flows  with  action-information 
requirements,  qualitative  and  quantitative  task  data,  and  man-machine  inter- 
face equipment  data  reflecting  both  related  tasks  and  hardware  characteristics. 
For  supporting  such  efforts,  DMS  is  readily  compatible  with  accepting  and 
producing  quantitative  data.  It  can  operate  effectively  with  terse  state- 
ments such  as  are  entered  in  functional  flows.  It  can  list  references  for 
cases  where  analyst  retrieval  and  review  is  appropriate.  However,  operation 
becomes  combersome  when  textual  material  is  desired  (e.g.,  mission  scenarios  - 
paragraph  2. 2. 1.2;  or  for  information-data  qualifications,  and  pilot  commen- 
tary - Figure  2.2-14).  Such  unwieldy  characteristics  can  be  somewhat  reduced 
if  text  is  reduced  to  terse,  indentured  outline  format. 

Accordingly,  information  that  could  be  stored  includes: 

Mission  Requirements 

o Outline  of  system  operational  requirements 
o Outline  of  mission  scenario 
o Mission  profile  data 
Functional  Flows 

o System  common  functions  (all  aircraft) 
o System  tvpe  functions  (e.g.,  fighter) 
o Mission  peculiar  functions 
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2. 3. 3. 3 


(Continued) 


Task  Data 
o Task  types 

o Quantitative  data  (e.g.,  reliability;  time;  accuracy) 
o Terse  outline  summaries  of  qualitative  data  (pilot  comments; 

trade-off  precautions) 
o Reference  topics  or  sources 
Man-Machine  Interface  Equipment  Data 

o Hardware  data  (physical  features;  performance  characteristics) 
o Related  tasks  and  task  data 
Other  Data 

o Human  anthropometry 
o Life  support  data 

The  areas  identified  above  are  preliminary,  but  offer  a framework  for  struc- 
turing major  topical  areas  relevant  to  systems  development  in  the  DMS . 

More  extensive  development  of  a manual  baseline  for  a total  system  concept 
is  desirable  in  order  to  more  clearly  isolate  and  designate  a taxonomy 
structure  for  each  of  the  areas.  Such  development  will  require  considerable 
care  and  attention  to  detail  in  order  to  maintain  cost  effective  operations 
of  the  DMS. 

An  added,  very  major  advantage  to  producing  such  a detailed  development 
(including  such  features  as  detailed  functional  flow  block  diagrams  and 
mission  time  lines)  is  the  carryover  knowledge  to  similar  weapons  systems. 
Each  generic  weapons  system,  such  as  a fighter  aircraft,  has  common  opera- 
tional requirements.  The  commonality  of  the  phase  activities  such  as 
pre-flight,  taxi,  take-off,  climb,  cruise,  etc.,  makes  it  unnecessary  to 
construct  an  entirely  new  set  of  functional  flows.  The  functional  flow 
block  diagrams  will  be  capable  of  covering  most  of  the  operational  require- 
ments for  each  new  systems  development.  The  individual  equipment  components 
may  vary  somewhat  and  mission  specific  activities  will  be  unique  to  a 
specific  weapons  system,  but  the  vast  majority  of  tasks,  types  of  subsystem 
components  and  activities  carried  out  by  the  crewman  will  be  identical  to 
previous  systems  or  sufficiently  similar  to  allow  rapid  assessment  of  areas 
unique  to  the  new  weapons  system. 


2.  3.4 


Function  Allocation  Model  (FAM) 
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2. 3. 4.1  Function  Allocation  Model  Concept 

The  Function  Allocation  Model  (FAM)  concept  is  among  the  most  complicated 
of  the  CAFES  submodels.  Accordingly,  it  will  be  summarized  in  more  detail 
than  the  others. 

The  FAM  and  al 1 other  CAFES  submodels  requires  the  human  factors  engineering 
analyst  to  obtain  detailed  operational  requirements,  mission  scenarios, 
functional  flow  block  diagrams,  and  mission  time  lines.  This  detail  is 
necessary  before  comprehensive  trade-offs  of  functions  and  tasks  are 
possible.  The  initial  production  of  the  necessary  input  data  requires 
concentrated,  dedicated  effort  on  the  part  of  the  human  factors  engineering 
analyst.  However,  processing  via  the  Function  Allocation  Model  is  rapid 
and  requires  minimal  time.  Following  the  computer  analysis,  the  analyst 
may  rapidly  progress  the  examination  of  a large  number  of  alternate  solutions. 

The  FAM  is  a CAFES  submodel  used  to  assist  the  human  factors  engineering 
analyst  to:  identify  and  allocate  the  tasks  and  functions  to  be  assigned  to 

each  crew-member.  Identify  required  equipment,  and  evaluate  selected  man/ 
machine  combinations.  The  human  factors  analyst  must  ultimately  decide 
whether  a man  is  to  perform  a given  function  or  whether  equipment  must  be 
provided  to  take  care  of  these  tasks.  In  certain  instances,  existing 
equipment  is  specified  for  use,  and  it  then  becomes  necessary  for  the  human 
factors  analyst  to  verify  that  functions,  tasks,  mission  objectives  and  opera- 
tional requirements  can  be  satisfied.  Once  this  requirement  is  satisfied, 
it  is  necessary  to  devise  an  optimum  arrangement  of  tasks  to  maximize 
mission  effectiveness  and  reliability. 

General  Functions  Allocation  Considerations 

The  allocation  of  functions  between  men  and  machines  is  an  inextricable  process 
of  system  design,  development  test,  and  evaluation.  As  such,  function  alloca- 
tion is  a multidiscipline  endeavor  in  which  hardware  and  software  designers 
work  in  cooperation  with  the  human  factors  specialist  to  design  the  optimum 
man-machine  system.  This  multidisciplinary  structure  has  resulted  in  the 
development  of  numerous  techniques  for  evaluating  crew-workstations,  man's 
functioning  in  the  workstation,  and  system  performance. 
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2. 3.4.1 


(Continued) 


Text  books,  technical  reports,  and  human  factors  engineering  manuals 
adequately  discuss  function  allocation  techniques.  They  provide  little 
help  in  defining  specific  procedures  for  the  process  of  function  alloca- 
tion. The  process  of  allocation  generally  falls  under  the  category  of 
"professional  Qualitative  judgment."  An  excellent  procedure  to  follow 
in  performance  of  this  "judgment"  is  as  follows: 

o Listing  and  analyzing  of  system  functions 

o Identifying  plausible  candidates  for  function  implementation 
o Identifying  criteria  for  function  allocation 

o Analyzing  data  related  to  above  criteria 

o Preparing  of  a comparison  matrix  that  exhibits  all  candidates 
versus  the  selected  criteria, 
o Performing  weighted,  quantified  evaluations 

o Selecting  and  justifying  of  the  allocation 

o Re-evaluating  and  periodically  updating  functions  allocated 

commensurate  with  availability  of  more  detailed  system  development 
data. 

t 

A traditional  allocation  method  is  "allocating  functions  on  the  basis 
of  what  man  does  best  and  what  machine  does  best."  There  are  several 
guidelines  that  should  be  considered  when  working  with  this  allocation 
method : 

o Allocating  functions  one  at  a time  to  either  man  or  machine  can 
lead  to  a solution  for  a full  set  of  mission  functions  if  done 
correctly. 

o Man  and  machine  are  interactive  in  many  functions  of  man-machine 
systems . 

o Function  allocation  is  not  necessarily  always  tied  to  which  sub- 
systems give  best  results,  that  is,  particular  situations  may 
demand  "non-optimum"  allocations  because  specific  equipment  must  be 
employed . 

o The  concept  implies  that  once  allocations  are  made  they  become 

permanent  assignments,  yet  the  optimum  solution  may  provide  flexi- 
bility for  changing  allocations  to  adapt  to  changing- situations. 
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(Cont  inued ) 


Another  task  is  the  ehoiee  of  allocation  criteria.  It  must  be  determined 
which  are  more  important,  and  by  what  relative  weighting?  Examples  of 
performance  criteria  are  task  execution  time  and  accuracy  of  task  per- 
formance. The  human  factors  engineer  is  responsible  for  establishing 
quantitative  values  for  these  criteria.  But  aside  from  these  primary 
criteria,  there  are  a host  of  secondary  criteria  which  can  significantly 
affect  allocation  decisions.  These  other  criteria,  many  qualitative, 

1 must  be  input  from  a source  outside  human  factors  technology.  Examples 
of  these  criteria  are: 

1.  Cost  (e.g.,  procurement;  operating) 

2.  Weight 

1.  Development  time 

4.  Development  risk 

5.  Safety 

6.  Maintainability 

7.  System  effectiveness  (e.g.,  targets  destroyed) 

8.  Physical  volume,  size  limits 

9.  Survivability 

'Hie  application  of  criteria  for  allocating  functions  provides  a basis 
for  determining  how  different  allocations  might  result  in  a different 
system  performance  or  cost-effectiveness.  However,  overall  system 
performance  is  related  to  (1)  how  system  performance  is  affected  by  human 
performance,  and  (2)  how  human  performance  is  affected  by  system,  mission, 
or  environmental  factors, 

FAM  Description 

The  FAM  offers  a method  for  evaluating  the  consequences  of  allocating  func- 
tions to  alternative  man-equipment  combinations.  Basic  inputs  to  the  model, 
as  well  is  to  other  CAFFS  models  are  from  the  mission  scenario,  function  and 
task  analysis  as  shown  in  Figure  2.3-6.  This  consists  of  a list  of  non- 
al  located  operational  functions  for  a prescribed  mission  and  a prescribed 
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Figure  2 . 3-6 : Function  Allocation  Model  (FAM) 
Input-Output  Diagram 
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system  scheme.  The  mission  function  list  could  result  from  development 
of  a detailed  functional  flow  block  diagram  or  could  simply  be  a list  of 
high  level  functions,  depending  on  how  far  definitive  system  development 
has  progressed.  The  function  list  is  an  essential  ingredient  in  function 
allocation,  as  mission  functions  must  first  be  identified  and  analyzed 
before  they  can  be  allocated  to  man  and/or  machine.  To  accomplish  this, 

FAM  operates  with  six  major  data  groupings: 

1.  Task  data 

2.  Mission  scenario  data 

3.  Tables  and  constants 

4.  Mission  objectives 

5.  Mission  events 

6.  Allocation  versions 

The  FAM  is  composed  of  two  main  data  processing  blocks:  The  Mission  Evaluator 
and  tiie  Procedure  Generator.  The  Mission  Evaluator  computes  mission  success 
probabilities  for  different  task  allocation  candidates,  and  tiie  Procedure 
Generator  produces  a task  sequence  based  on  task  allocations  and  procedural 
rules  and  constraints.  The  Mission  Evaluator  is  used  to  rank  order  all  the 
different  variations  in  task  allocation  that  are  under  consideration,  whereas 
the  Procedure  Generator  is  used  to  do  a refined  analysis  (e.g..  Operational 
Sequence  Diagrams)  for  allocation  candidates  that  are  selected  as  most 
promising.  Primary  inputs  and  outputs  of  these  two  main  processors  are 
illustrated  in  Figure  2.3-6.  Each  data  entry  item  (task  input  data)  will 
be  defined  first.  When  this  is  completed  for  all  items,  their  uses  in 
producing  the  desired  FAM  results  will  then  he  described. 

MISSION  EVAl.l'ATOR 

[lie  Mission  Evaluator  uses  mission  scenario  task  data  in  the  form  of  a 
tabular  list  of  mission  tasks,  number  of  task  occurrences,  start  time  for 
each  occurrence  and  time  duration  fee  each  occurrence  - in  effect,  a task 
tin.'  list.  If  desired  by  the  HFE  analyst,  it  may  use  task  load  ratings 
(Table  2.1-3)  as  a time  stress  modifier  to  scale  task  execution  times  or 
to  prioritize  t isks.  It  operate:,  witli  specif  ii  objectives,  such  as  the 
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"intermediate"  mission  objectives:  (a)  threat  detection  and  suppression; 

(b)  navigation  to  target  vicinity;  (c)  target  acquisition;  (d)  weapon  delivery, 
or  (e)  damage  assessment.  A conceptual  framework  for  one  such  objective, 
target  detection,  with  five  detection  modes  and  both  parallel  and  sequential 
operations,  is  illustrated  in  Figure  2.3-7.  System  task  reliabilities  for 
each  task  in  the  sequence  are  computed  for  both  operator  and  equipment,  on 
the  basis  of  which  subsystems  are  allocated  to  the  task,  their  type  of 
parallel-redundant  relationships  and  task  performance  reliabilities  for  both 
operator  and  equipment.  Examples  of  allocations  that  might  be  evaluated  are 
illustrated  in  Table  2.3-4.  In  the  mission  evaluator,  variable  weighting 
factors  for  critical  tasks  (e.g.,  target  tracking  vs.  navigation)  can  be 
used  if  desired.  Probability  of  success  for  the  intermediate  mission  objec- 
tive is  then  computed  by  standard  reliability  methods,  e.g.,  following  the 
rules  for  parallel,  redundant  or  sequential  reliabilities.  Overall  mission 
success  can  be  similarly  estimated  by  accumulating  reliabilities  for  performance 
of  "intermediate"  mission  objectives. 

Task  allocation  versions  are  created  by  integrating  a concept  for  the  tasks, 
the  operators  and  the  hardware  subsystems  under  consideration.  This  combining 
process  results  in  candidate  crew  member  and  equipment  assignments  for  the 
specified  mission  tasks.  Included  in  the  task  allocation  is  a definition  of 
how  tasks  are  assigned  in  cases  where  two  or  more  subsystems  are  allocated 
to  the  same  task.  These  are  cases  of  redundant  assignment  to  improve  overall 
task  reliability. 

The  computer  can  accommodate  a large  number  of  different  allegations,  there- 
fore there  is  no  necessity  to  defend  any  particular  version  as  the  best  choice 
prior  to  Function  Allocation  Model  execution.  Traditionally  the  human  factors 
engineer  is  asked  to  derive  one  best  choice  which  is  difficult  to  defend 
on  a quantitative  basis.  Through  quantitative  allocation  analysis,  the  human 
factors  engineer  is  relatively  free  in  his  selection  of  candidate  allocation 
versions  and  to  exercise  professional  judgment  in  both  his  selection  of 
practical  candidates  and  his  comparative  evaluation  of  quantitative  results. 
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EXAMPLES  OF  SUBSYSTEM  ALLOCATIONS 


Subsystem  allocations  to  a task: 


1.  One  crew  member  only. 

2.  One  equipment  type  only. 

3.  Two  crew  members  - parallel  redundant. 

4.  Two  crew  members  - sequential  redundant. 

5.  Two  equipments  of  same  type  in  parallel. 

6.  Two  equipments  of  different  type  in  parallel. 

7.  One  crew  member  and  one  equipment  in  parallel. 

8.  Two  crew  members  and  one  equipment  in  parallel. 

9.  Two  crew  members  in  parallel  with  a third  crew 
member  as  back-up. 


2. 3.4.1  (Continued) 

Referring  again  to  Figure  2.3-6,  the  next  Function  Allocation  Model  input  item 
is  task  performance  data.  These  data  are  used  to  compute  mission  success 
probabilities  for  the  different  allocation  versions  as  is  explained  later  in 
this  section.  Task  data  included  under  this  category  are: 

1.  Operator  reliability  as  a function  of  task  execution  time. 

2.  Nominal  task  execution  time. 

3.  Equipment  reliability. 

4.  Task  load  ratings. 

5.  Task  priority. 

6.  Task  interruptability  classification. 

7.  Task  symbol. 

8.  Task  classification. 

9.  Action  mode. 


Parameters  1-4  are  used  in  the  Mission  Evaluator  and  parameters  5-9  are  used 
solely  by  the  Procedure  Generator,  which  is  discussed  in  the  following  text. 

The  output  of  the  Mission  Evaluator  section  of  the  Function  Allocation  Model 
is  a table  of  mission  objective  success  probabilities  (Po)  for  each  alloca- 
tion version  and  each  different  mission  objective  specified. 

PROCEDURE  GENERATOR 

The  purpose  of  the  Procedures  Generator  is  to  apply  a list  of  all  mission  tasks 
against  a specific  scenario  and  ask  the  question  "who  is  doing  what,  and  when". 
Activity  sequencing  is  determined  by  the  Procedure  Generator  which  observes 
rules  and  constraints  prescribed  by  the  HFE  user.  These  rules  and  constraints 
include : 

1.  Prerequisite  tasks 

2.  Mandatory  procedures 

3.  Required  simultaneity  and  task  overlap  exclusions 

4.  Earliest  and  latest  task  start  times 

5.  Interruptability  constraints 

6.  Maximum  task  loads  per  operator 
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The  Procedures  Generator  combines  data  with  other  Function  Allocation 

Model  inputs,  such  as  candidate  functions  allocations,  task  execution  times, 
and  task  priorities  to  produce  a task  sequence  for  each  operator  in  a crew- 
station.  Both  tabular  and  statistical  outputs  are  produced.  Tabular  outputs 
are  sufficient  to  construct  Operational  Sequence  Diagrams  (these  diagrams 
are  not  a current  CAFES  capability).  Statistical  outputs  covering  task 
loading  variables  (Table  2.i-r>)  can  include  such  information  as  percent 
of  time  each  crew  member  is  busy,  or  percent  of  time  only  one  task  is  being 
executed  by  the  crew. 

AIL  of  these  output  data  assist  in  the  detailed  evaluation  of  allocation 
versions,  and  they  provide  both  quantitative  and  qualitative  comparisons. 

For  example,  as  function  allocations  are  varied,  the  degree  of  operator 
interaction  is  affected  (reflected  in  Operational  Sequence  Diagram  data) 
as  is  the  number  of  tasks  that  can  be  accomplished  in  a given  time  interval 
(statistical  data).  The  Procedure  Generator  complements  the  Mission 
Evaluator  because  it  provides  further  evidence  to  support  a selection  of 
function  allocation  versions  for  more  detailed  evaluation  (e.g.,  by  the 
Workload  Assessment  Model,  the  Computer  Aided  Design  of  Crewstation  Model, 
etc.  ) . 

FUNCTION  ALLOCATION  MODEL  OUTPUTS 

Overall  FAM  operations  and  outputs  are  summarized  in  Figure  2.3-8  and  2.3-9. 
The  two  FAM  submodels  can  produce  the  following  outputs,  according  to  specific 
constraints  (e.g.,  time)  input  by  the  HFE  user: 

Mission  Evaluator  Highlights 

Mission  objec.tive(s)  reliability  estimates 
Overall  mission  reliability  estimates 
Perceived  task  load 

Integrated  Task  reliabilities 

Procedures  Generator  Highlights 

Percent  of  tasks  interrupted  and  completed 
Percent  of  tasks  interrupted  and  not  completed' 

Percent  of  tasks  not  started 
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TABLE  2.3-5  STATISTICAL  OUTPUT  FROM  PROCEDURE  GENERATOR 

1.  List  of  scheduled  tasks  that  were  not  started 
at  any  time. 

2.  List  of  scheduled  tasks  that  were  started  but  not 
completed. 

3.  List  of  scheduled  tasks  that  were  interrupted  and 
not  completed. 

4.  List  of  scheduled  tasks  that  were  started  late. 

5.  List  of  scheduled  tasks  that  were  interrupted  and 
completed. 

6.  Percentages  of  total  tasks  in  categories  (a) 
through  (e). 

7.  Percent  of  time  only  one  task  was  being  done. 

8.  Percent  of  time  two  tasks  were  being  done. 

9.  Percent  of  time  three  or  more  tasks  were  being  done. 

10.  Percent  of  time  each  operator  is  busy. 


Analyst  Produce  General 


FAM  OPERATIONS 


FAM  PRODUCT 


MISSION  EVALUATOR 

• Operate*  on  \ 

- System  Task  Lift 

- Alternative  Levels 
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- Man-Equipment 
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and  Equipment 
Performance 
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--  Reliability  ^ 
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Integrates  Data  for 

e Total  Mission 
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PROCEDURES  GENERATOR 

e Operates  on  j 

- Task  Data  (E.G.  Time)  « 

- Task  Allocations 

- Task  Priorities 

- Procedural  Constraints 
(E.G.  Pre-Requisites) 

e Summarizes 

- By  Time  Sequences 

- In  Context  of  Constraints  • 


Produces 

e Detailed  Ta A 
Sequence 
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’ # Operations  Time 
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OUTPUTS 

• 

Performance  Feasibility 
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• 
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Allocation  Combinations 
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• 

Operational  Sequence 
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• 

Baseline  for  Allocation 
Changes 

FIGURE  2.3-9:  FAM  MODEL  DESCRIPTION-OPERATIONS  AND  OUTPUTS 
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2.  3.4.1 


(Continued) 


Percent  of  tasks  started  but  not  completed 

Percent  of  tasks  started  late 

Percent  of  time  operator  busy 

Tasks  interrupted  and  completed 

Tasks  not  started 

Task  simultaneity  status 

Tasks  started  late 

Additionally,  the  FAM  can  output  a detailed  task  timeline  (much  as  is  illus- 
trated in  Figure  2. 3-10) as  an  input  for  the  Workload  Assessment  Model. 

2. 3.4.2  Function  Allocation  Model  Requirements  Specification 

The  overall  objective  of  the  Function  Allocation  Model  (FAM)  is  to  assist 
the  human  factors  engineer  in  identifying  function  allocations  which  are 
promising  candidates  for  detailed  evaluation  (e.g.,  workload  analysis,  crew 
station  design).  Achievement  of  this  objective  implies  compliance  with  a 
number  of  general  and  specific  design  requirements.  The  general  FAM  design 
requirements  specification  included: 

o The  FAM  shall  produce  data  to  assist  selection  of  function  allocation 
candidates  but  leave  final  selection  to  professional  judgment  of  the 
human  factors  engineer. 

o The  FAM  shall  provide  quantitative  comparisons  of  allocation  alterna- 
tives on  the  basis  of  explicit  criteria  and  provide  traceability  of  all 
assumptions . 

o The  input  and  output  formats  for  the  FAM  shall  be  designed  for  ease  of 
use  and  interpretation  by  human  factors  engineers, 
o The  FAM  shall  be  consistent  with  CAFES  objectives  and  shall  be  designed 
for  efficient  interface  with  all  other  CAFES  submodels, 
o The  FAM  shall  provide  flexibility  and  options  for  by-passing  detailed  or 
complex  portions  of  the  model  when  such  details  are  not  required  or 
are  not  warranted  for  a given  analysis.  This  flexibility  shall  include 
the  specification  of  model  input  data, 
o The  FAM  shall  be  constructed  on  a modular  basis  for  efficient  model 
update  or  future  modification,  and  also  to  facilitate  operational 
flexibility . 


MiSunf  PUSlUON 

Cti«i  HUNtnlNUKUr't 


B « I iNIUrtTt  *1  Hi  !hc  MHNtUVt 
OtLM  "u)«i 

0)1  SliM.1  »«  ‘IXNHlI  Il'jSlit 
an  «.  *>*  m.nkoupi 


8 ?.l  tXttUU  r*(  H II  Ml  « 0*»«* 

Ufl*l  MUNI  MlNftNL'tPf 

6 . I . 1 M.JNI  TON  n|  iJl,  t ► I iuMl 

l»  V»l  HIINl.M|NUNLf.PT 

7.17.1  A It#  »,  lU-T  ruin 

i»  i m mun  nIMtNi'fPf 


.81  LMLWlr 


) . MUNI  MX  l> 


6 121  f nMMlNt 


i sufcr 


FIGURE  2.3-10 


DETAILED  TASK  TIMELINE 
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2.  3.4.2 


(Cont inued) 


o The  detailed  structure  of  the  FAM  shall  be  designed  for  growth  potential 
to  accommodate  new  types  of  data  and  parametric  relationships  as  they 
become  available. 

Detail  design  requirements  specifications  included: 

o The  FAM  shall  provide  means  for  identifying  functions  or  tasks  and  how 
each  is  allocated  to  man  and/or  machine.  Tasks  shall  be  identifiable 
by  name,  symbol,  and  number  (e.g.,  decimal  number  indent ure according  to  the 
task's  position  in  a functional  flow  block  diagram).  Allocations  for 
each  task  shall  be  to  one  or  more  operators  (20  maximum),  to  combination 
of  man  and  machine,  or  to  machines  only.  When  allocations  are  to  more 
than  one  operator/machine,  the  type  of  redundancy  shall  be  defined, 
i.e.,  parallel  or  sequential  redundancy.  Combinations  of  redundancy 
types  are  also  allowed.  For  example:  two  operators  in  parallel  with 

a machine  back-up  (sequentially  redundant) . 

o Provision  shall  be  made  to  specify  up  to  20  different  allocation  versions, 
where  each  version  is  a complete  list  of  all  mission  tasks  (together 
with  how  each  task  is  allocated).  The  FAM  shall  be  capable  of  fully 
specifying  all  allocation  versions  from  a user  prepared  input  of  one 
complete  version  (standard  version)  and  a statement  of  exceptions  to  the 
standard  for  each  additional  version. 

o The  F.AM  shall  provide  for  retrieval  and  display  of  allocation  versions 
and  for  easy  revision  of  allocation  versions. 

o The  FAM  shall  determine  how  different  allocation  versions  affect 

mission  success  by  computing  probabilities  of  mission  success  for  each 
allocation  version.  Mission  success  estimates  shall  be  dependent  on 
task  performance  which,  in  turn,  shall  be  dependent  on  how  tasks  are 
allocated  to  man  and/or  machines.  Task  performance  data  for  operators 
and  equipment  shall  be  input  to  FAM  and  these  data  combined  to  compute 
mission  success  probabilities. 

o Operator  task  performance  data  shall  be  in  terms  of  nominal  error  rate 
(or  reliability),  nominal  task  execution  time,  and  a function  describ- 
ing how  task  reliability  varies  with  task  execution  time.  FAM  shall 
accommodate  and  utilize  task  performance  data  which  can  vary  with 


2. 3. 4. 2 (Continued) 

operational  situation  (e.g.,  aircraft  cruise,  aerial  '’ombat,  terrain 
following  etc . ) . 

o FAM  shall  provide  an  option  to  either  input  the  task  reliability  versus 
task  time  functions  as  a table  of  points  (15  pairs  maximum)  or  as 
segments  of  second-degree  polynomials  (10  segments  maximum) . 

o FAM  results  shall  be  sensitive  to  assumptions  in  the  njission  scenario. 

That  is,  mission  success  predictions  shall  depend  on  the  sequence  of 
mission  tasks  that  reflect  assumptions  on  the  type  and  timing  of  mission 
events.  This  dependence  on  scenario  can  be  implemented  by  allowing  the 
task  sequence  to  impact  time  available  to  perform  the  tasks,  which  in 
turn  affects  task  performance  characteristics  (via  task  reliability- 
versus-task  time  stress  functions). 

o Provisions  shall  be  made  for  storage,  retrieval  and  display  of  mission 

scenario  data  which  consist  of  (a)  list  of  mission  event  names,  (b)  event 
times,  (c)  mission  task  names,  (d)  time  at  which  each  task  begins, 

(e)  task  performance  time  intervals  and  (f)  operational  situations  under 
which  each  task  is  being  performed  (e.g.,  aircraft  dive,  evasive  maneuver, 
etc.).  Provision  shall  be  made  for  easy  modification  of  mission  scenario 
data . 

o FAM  shall  make  first  order  estimates  of  crew  workload  during  a mission 
for  use  in  scaling  nominal  task  execution  times  in  order  to  reflect 
variations  within  and  between  different  mission  scenarios.  Derived 
workload  parameters  shall  include  task  difficulty  factors  such  as 
precision,  concentration,  criticality,  mission  priority,  and  task 
continuity.  Numerical  ratings  shall  be  assigned  to  these  factors  and 
the  values  shall  be  dependent  on  operational  situation.  These  workload 
estimates  shall  be  used  to  modify  task  execution  time,  which  then  impacts 
task  performance  and  therefore  affects  mission  success  estimates. 

o FAM  shall  assist  in  evaluation  of  allocation  alternatives  by  developing 

operational  procedures  for  specified  task  allocation  versions.  Procedure 
data  generated  by  FAM  shall  be  sufficient  to  construct  Operational 
Sequence  Diagrams  (OSD's)  by  manual  or  computer  methods.  Outputs  for 
the  OSD  data  and  symbology  information  shall  be  consistent  with  standard 
me  thods . 


2. 3.4. 2 


(Continued ) 


o Inputs  for  operational  procedures  that  shall  be  generated  by  the  KAM  to 
be  consistent  with  user  defined  rules  and  constraints  such  as  task 
prerequisites,  task  simu ltaniety , priorities,  earliest  start  times, 
latest  start  times.  The  KAM  shall  be  designed  for  ease  of  input  and 
modification  of  these  procedural  data. 

2.3.4. 3 Function  Allocation  Model  Relationship  to  Baseline  HFE 

Methodology 

FAM  use  requires  data  described  in  the  baseline  methodology  section  from  the 
scenario,  functional  flows  and  alternate  equipment  candidates,  including 
machine  reliability,  task  reliability  and  task  time.  It  can  accept  and  use 
this  data  at  different  levels  of  detail  or  indenture,  depending  on  analyst 
preference  and  availability  of  associated  time  and  reliability  data.  Most 
desirably,  the  vast  majority  of  data  would  be  in  considerable  detail,  avail- 
able in  storage  and  retrievable  for  ready  decisions  and  mode]  operations. 

FAM  picks  up  where  the  baseline  methodology  leaves  off,  extending  the  process 
to  provide  comparative  appraisals  of  alternative  combinations  of  equipment. 
Many  user  options  exist,  with  the  simplest  being  based  on  a cumulation  of 
task  and  equipment  reliabilities  to  produce  an  overall  reliability  estimate 
for  each  combination.  Other  options  include  such  variations  as  incorpora- 
tion of  the  constraints;  a time  stress  weighting  factor;  and  reliability 
variations  according  to  criticality  or  time  stress.  The  extent  to  which 
detailed  data  requirements  might  be  necessary  to  exercise  the  options  is 
illustrated  by  the  Table  2.3-6  Summary  of  FAM  Inputs. 

A considerable  number  of  elements  in  the  FAM  operation  could  be  better  defined 
for  the  user  by  extending  the  baseline  process  described  to  a total  mission, 
as  described  under  DMS  discussion.  This  extension  should  include  application 
and  evaluation  oi  various  FAM  options.  Much  of  the  HFF.  effort  for  any  new 
system  could  then  be  signi t icant ly  reduced  through  maximum  utilization  of  pre- 
existing groundrules  data,  ratings  and  application  procedures. 
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TABLE  2.3-6: 

(MISSION  EVALUATOR) 

Average  task  reliability 

Machine  reliability 

Mission  objective 

Mission  scenario 

Mission  start  time 

Mission  stop  time 

Mission  time  interval  size 

Nominal  task  execution  time 

Operator  reliability 

Reliability  data  number 

Reliability  curve  segment  data 

Reliability  weighting  coefficients 

Scenario  events 

Situation 

Slide  steptime  interval 
Stress  correction  factor 
Task  name 

Task  allocation  version 

Task  event 

Task  ID  number 

Task  load  score 

Task  start  time 

Task  time  scaler 

Time  compression  factor 
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FAM  INPUTS 

(PROCEDURE  GENERATOR) 

Action  mode 
Earliest  start  time 
Interruptabi lity  classification 
Latest  start  time 
Nominal  task  execution  time 
Number  of  task  repetitions 
Priority 
RNO-Function 
Rule  constraints 
Scenario  event 
Situation 
Task  name 

Task  allocation  version 

Task  classification 

Task  event 

Task  ID  number 

Task  load  score 

Task  symbol 

Umbrella  tasks 


2.3.4.)  (Continued) 

Additionally,  FAM  refinements  should  be  incorporated  to  enhance  user  inter- 
tare  operations,  including  input  and  output  formatting  and  interpretation. 


In  addition  to  data  described  under  DMS  discussion,  major  data  elements  that 
could  be  stored  for  FAM  use  include: 

Task  ime 

Task  reliability 

Machine  reliability 

I'ask  criticality  ratings 

Mission  stress  adjustment  data 

Task  time  compression  data 


2.3.  5 


Workload  Assessment  Model  (WAM) 


2. 3.5.1  Workload  Assessment  Model  Concept 

Basic  requirements  for  initiating  workload  appraisals  are  that  functions 
be  allocated,  that  candidate  equipment  concepts  and  task  details  be 
identified,  and  that  detailed  task  timelines  and  time  constraints  be 
known.  Information  is  summarized  in  a detail  task  timeline,  which  may  be 
produced  as  a FAM  output,  or  from  detailed  development  of  all  necessary 
tasks  to  meet  the  objectives  of  a mission  or  a mission  segment  including  a 
critical  task  series.  Early  evaluations  may  be  desired  to  establish  con- 
figuration design  or  preliminary  design  concepts  prior  to  starting  develop- 
ment of  a crew  station  configuration.  Iterative  evaluations  are  desirable 
with  tlie  evolution  of  detailed  hardware  definition  and  development  to  con- 
firm continued  suitability  of  crew  workload  with  progressive  design  deci- 
sions. Alternatively,  the  configuration  may  be  fixed  before  it  is  determined 
to  be  desirable  to  evaluate  workload  conditions. 

The  task  timeline  chart  is  the  basic  tool  for  initiating  workload  analyses. 

It  illustrates  detailed  task  sequencing  and  timing  for  one  or  more 
operators  as  function  of  mission  elapsed  time.  While  the  timeline  may  be 
produced  by  the  FAM,  they  have  been  most  typically  produced  manually  to 
result  in  formats  such  as  the  one  shown  in  Figure  2.3-10  or  the  two  types 
shown  in  Figure  2.3-11. 

On  a manual  basis,  the  HFE  analyst  can  review  the  task  - timeline  charts, 
evaluate  task  elements  for  possible  difficulties,  and  examine  proximal  and 
simultaneous  tasks  to  identify  high  workload  or  potential  overload  periods. 
Accordingly,  tasks  or  subsystems  contributing  to  such  loads  are  readily 
identifiable.  Given  mission  time  constraints,  e.g.,  weapon  delivery,  he 
can  readily  determine  whether  it  is  feasible  to  complete  all  necessary 
tasks  in  time,  and  can  determine  such  feasibility  for  both  normal  and 
degraded  modes.  Results  of  such  analyses  can  then  be  used  to  modify  one 
or  more  of  the  following: 
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(Cont inued) 


o Crew  size 

o Man-machine  task  allocation 

o Intra-crew  task  allocation 

o Operational  procedures  (task  sequence) 

o Mission  requirements 

o System  cost  goal 

Through  successive  iteration  of  possible  trade-offs,  the  human  factors 
engineer  can  derive  the  best  overall  solution  to  high  task  load  or  over- 
loading conditions.  However,  the  workload  analysis  method  may  be 
laborious,  and  a moderate  number  of  analysis  iterations  may  not  be 
feasible  by  manual  methods.  Under  these  conditions,  computer  augmentation 
of  workload  analysis  can  be  of  considerable  assistance. 

In  WAM  the  overall  workload  evaluation  process  is  simplified  and  made  less 
judgmental  following  the  processes  outlined  in  Figures  2.3-12  and  2.3-13. 
Input  data  can  be  constructed  by  the  analyst  in  simple  tabular  format 
which  can  be  organized  by  tiie  computer  in  a format  similarly  to  the  listings 
of  Tables  2.3-7  and  2.3-8. 

WAM  may  be  applied  for  single  or  multiple  crewmen.  However,  the  workload 
is  analyzed  independently  for  each  crewman,  and  the  tabular  and  graphical 
outputs  will  be  specified  by  crewmen.  Reports  provide  tabular  and  graphical 
workload  data  for  each  crewman  and  eight  channels  of  activity  (reflecting 
Crewman,  External  Vision,  Internal  Vision,  Left  Hand,  Right  Hand,  Left  Foot, 
Right  Foot,  Cognitive,  Auditory  and  Verbal).  Graphical  reports  currently 
available  include: 

1.  Play  back  of  the  task  timeline  in  t he  form  of  an  I bar  chart  (an 

element  that  can  also  be  produced  by  FAM  for  WAM  input  data). 

2.  Workload  time  history  (by  channel  and  averages) 

3.  Workload  barchart  (with  and  without  one  sigma  deviations  reflecting 
channel  loading  variations  over  the  course  of  the  mission) . 
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COMPUTE*  A IOEO  FUMCTION-ALIOCATIOM  EVALUATION  SYSTEM 


BEGIN  CAFES*  CREATE  NEK  OATA  SANK/ 

BEGIN  OATA  BANK  ECITOR/  Cl*  PILOT/ 

TASK*  5.1  MAINTAU  FLIGHT  CONTROL/ 

ALLOCATION  LCGIC*  Cl/ 

SITUATION*  CLOSE  AIR  SUPPORT/ 

CHANNEL*  Cl/  EV*70.  / IV-30.  / LM-100./ 
COG*tO.  / A UO  *0  . / VERB*  0.  / 

TASK*  5.2  CHECK  FLIGHT  INSTRUMENTS/ 
ALLOCATION  LOGIC*  Cl/ 

SITUATION*  CLOSE  AIR  SUPPORT/ 

CHANNEL*  Cl/  E V*  0 . / IVzlOO./  LH*0.  / 

C OG * 3 0 . / A UO  = 0 • / VERB-0.  / 

TASK*  5.2.1  CHECK  FLIGHT  INSTRUMENTS/ 
ALLOCATION  LOGIC*  Cl/ 

SITUATION*  CLOSE  AIR  SUPPORT/ 

CHANNEL*  Cl/  E V * 1 0 . / IV  = 9 0 • / L H*  25 . / 
COG-30.  / A UO  =0 . * / VERB-0.  / 
TASK*  5.2.2  CHECK  ''LIGHT  INSTRUMENTS/ 
ALLOCATION  LCGIC*  Cl/ 

SITUATION*  CLOSE  AIR  SUPPORT/ 

CHANNEL*  Cl/  E V * 10 . / I V = 9 0 . / LH-100./ 
COG-LO.  / A UO  = 0 . / VERB*  0 . / 

TASK*  5.2.3  CHECK  FLIGHT  INSTRUMENTS/ 
ALLOCATION  LCGIC*  Cl/ 

SITUATION*  CLOSE  AIR  SUPPORT/ 

CHANNEL*  Cl/  EV-JO.  / I V * 7 0 . / LH=80.  / 
C OG  = 5 0 . / A UO  * 0 • / VE»8*0.  / 

TASK-5.2.4  CHECK  FLIGHT  INSTPUHENTS/ 
ALLOCATION  LCGIC*  Cl/ 

SITUATION*  CLOSE  AIR  SUPPORT/ 

CHANNEL*  Cl/  E V*  20 . / I V = ft  C . / L H* 10  0./ 
C OC  * 3 0 . / AUO*0.  / VERB-0.  / 
TASK*  5.2.5  CHECK  FLIGHT  INSTRUMENTS/ 
ALLOCATION  LOGIC*  Cl/ 

SITUATION*  CLOSE  AIR  SUPPORT/ 

CHANNEL*  Cl/  E V * b 0 . / I V = <♦  0 . / LH=100./ 
COG  =4  0 . / AUO-O.  / VERB-0.  / 
TASK*  5.2.5  CHECK  FLIGHT  INSTRUMENTS/ 
ALLOCATION  LCGIC*  Cl/ 

SITUATION*  CLOSE  AIR  SUPPORT/ 

CHANNEL*  Cl/  _ U = 1 0 . / I V * 9 0 . / LH*o0.  / 

COG  = 3 0 . / A UO  = G . / VtRB*0.  / 

TASK*  5.2.7  CHE  C z FLIGHT  INSTRUMENTS/ 
ALLOCATION  LCGIC*  Cl/ 

SITUATION*  CLOGC  AIR  SUPPORT/ 

CHANNEL*  Cl/  EV=>.0.  / I V *6C  . / LH*80.  / 
COG  * h 3 . / A UO  = 0 . / VERB*  0.  / 

TASK*  5.2.3  CHECK  FLIGHT  INSTRUMENTS/ 
ALLOCATION  LCGIC*  Cl/ 

SITUATION*  CLOSE  AIR  SUPPORT/ 

CHANNEL*  Cl/  E V * 3 0 . / IV*70.  / L H*  1 0 • / 
COj-20.  / A UO  = 0 . / V£RB*0.  / 

TASK-  5.3  CHECK  ENGINE  INSTRUMENTS/ 


RM* 100./  LF»10. 
END  CHANNEL/ 


/ «F*U.  / 


RH*  0 . / LF*0. 

END  CHANNEL/ 


/ RF*0.  / 


RH-70.  / LF  = 25 , 
ENO  CHANNEL/ 


/ RF*25.  / 


RH* 10  0 ./  LF=20. 
ENO  CHANNEL/ 


/ RF*20.  / 


RH=10fl./  LF*20 , 
ENO  CHANNEL/ 


/ RF*  20.  / 


RH-130./  LF*10. 
ENO  CHANNEL/ 


/ RF  * 1 0 . / 


RH* 1 0 0 . / LF*#0. 
ENO  CHANNEL/ 


/ RF*00.  / 


RH*70.  / Lr* 20 . 
ENO  CHANNEL/ 


/ RF-20.  / 


RH  * l 0 0 > / LF»50. 
ENO  CHANNEL/ 


/ RF*»  0.  / 


KH  = 6 0 . / LF«10. 
ENO  CHANNEL/ 


/ RF*10.  / 


TAS-  TNPUT 
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1 


(START  - $./  E OUR*  T I ON*  1.0/ 

EVENT-  2/  (TASK*  5.2.1  / (SITUATION 

(START-  3./  EOURATI ON-  3.0/ 
EVENT-  3/  (TASK-  5.3.1  / (SITUATION 

(START-  6./  E OURA  T I ON-  2.0/ 
EVENT-  4/  (TASK-  5.4.1  / (SITUATION 

(START-  0./  E OUR A T I CN-  1.5/ 
EVENT-  5/  (TASK-  5.5  / (SITUATION 

(START-  10./  EOURATION-  2. £/ 
EVENT-  6/  (TASK-  S. 2.1  / (SITUATION 

(START  - IT./  EOURATION*  1.5/ 
EVENT-  T/  ETASK-  8.2.1  / (SITUATION 

ESTART-  19./  EOURATION-  1.5/ 
EVENT-  6/  (TASK-  8.2.3  / (SITUATION 

ESTART*  21./  EOURATION-  2.5/ 
EVENT-  9/  ETASK-  8. 2. A / (SITUATION 
(START-  25./  EOURATION-  6.0/ 
EVENT-  10/  E TASK-  8.2.5  / (SITUATION 

ESTART-  32./  EOUR ATI CN -12.0/ 
EVENT-  11/  ETASK*  8.2.4  / (SITUATION 

ESTART-  44./  EOURATION*  4. C/ 
EVENT-  12/  (TASK*  8.2.5  / (SITUATION 

ESTART-  48./  EOURATION-'  4.0/ 
EVENT-  13/  ETASK*  8.2.4  / (SITUATION 

(START-  53./  EOURATICN-  6.0/ 
EVENT-  14/  ETASK*  8.2.5  / (SITUATION 

ESTART*  59./  EOURATION-  2.0/ 
EVENT-  15/  ETASK-  8.2.6  / (SITUATION 

ESTART-  63./  E OUR A TI CN « l 0 . 0/ 
EVENT-  16/  ETASK*  8.2.4  / (SITUATION 

ESTART*  24./  EOURATION-  3.0/ 
EVENT-  17/  ETASK-  8.2.5  / (SITUATION 

ESTART-  77./  EOURATICN*  1.0/ 
EVENT-  16/  ETASK*  8.2.4  / (SITUATION 

ESTART*  62./  EOURATION*  6.0/ 
EVENT-  19/  ETASK-  6.2.5  / (SITUATION 

ESTART*  68./  EOURATICN-  3.0/ 
EVENT-  20/  ETASK-  6.2.4  / (SITUATION 

ESTART-  91./  EOURATION*  3.0/ 
EVENT-  21/  ETASK*  8.2.5  / (SITUATION 

(START*  94./  EOURATION*  *.0/ 
EVENT-  22/  ETASK-  5.2  / (SITUATION 

ESTART -1QQ./  EOURATICN-  3.0/ 
EVENT*  23/  ETASK-  5.4  / (SITUATION 

ESTART -103./  EOURATION-  1.0/ 
EVENT-  24/  ETASK*  5.5  / (SITUATION 

(START-104./  EOURATION-  1.5/ 
EVENT-  25/  ETASK*  8.4.1  / ESITUATION 

ESTART-106./  EOURATICN*  2.  C/ 
EVENT-  26/  ETASK*  8.2.J  / ESITUATION 

ESTART -108./  EOURATICN-  2.5/ 
EVENT-  27/  ETASK-  8.2.3  / (SITUATION 

ESTART -111 ./  EOURATICN*  1.5/ 
EVENT-  28/  (TASK-  8.2.3  / ESITUATION 

ESTART -113./  EOURATICN-  1.5/ 
EVENT-  29/  ETASK-  8.5.4  / ESITUATION 

ESTART -115./  EOURATION-  4.0/ 
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2.3.5. 1 


(Continued) 


summarize  tabular 
time  along  the 
the  task  and  in 


Timeline  plots(Figure  2.3-10)  can  be  produced  by  WAM  to 
inputs.  Plots  are  a chart  of  tasks  on  the  ordinate  and 
abscissa.  Task  execution  is  depicted  by  a bar  opposite 
the  time  frame  performed. 


The  Workload  Barchart  and  Barchart  Plus  One  Sigma  variation  plot  provides 
a graphical  representation  of  the  statistical  analysis  performed  on  channel 
activity.  The  bars  represent  average  activity  channel  and  collective 
averages  of  visual,  motor,  communication  and  overall  activity.  This 
presentation  can  be  used  for  quick  overviews  of  workload  comparisons 
between  crew  members,  between  channels,  between  mission  phases/situations, 
or  between  different  candidates  for  function  allocation,  system  design,  and 
operating  procedures. 


The  operator  workload  versus  time  is  a graphical  representation  with  lines 
connecting  to  workload  level  at  a midpoint  of  its  time  segment.  This 
graphical  representation  provides  the  instantaneous  level  up  to  a maximum 
of  160%.  Individual  channel  activities  (internal  vision,  external  vision, 
left  hand,  etc.)  are  depicted,  as  well  as  group  and  total  averages.  The 
production  of  the  graphical  output  provides  a readily  understandable  means 
of  identifying  potential  problem  areas  and  the  means  to  convey  these 
concerns  to  parties  concerned  wit!)  the  selection  of  the  desired  configura- 
tion and  design. 


Task  shifting  ‘or  less  critical  tasks  is  an  HFE  analyst  option.  Provisions 
are  made  in  the  Workload  Assessment  Model  operations  to  automatically 
rearrange  the  times  which  specified  tasks  identified  as  not  time  critical 
may  be  executed.  A "shifting"  feature  attempts  to  move  the  large  time 
non-critical  activities  out  of  an  overloaded  time  segment  by  shifting  to 
later  time  segments  or  earlier  time  segments.  The  Lask  or  tasks  will  be 
shifted  if  overloading  of  other  time  segments  will  occur.  The  amount  of 
departure  from  the  nominal  start  time  is  within  preassigned  limits  in 
which  shifting  can  occur.  No  shift  occurs  when  the  realignment  of  tasks 
forces  a new  Lime  segment  into  an  overload  situation.  Those  segments 
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2. 3.5. 1 


(Continued) 


that  can  be  shifted  successfully  are  identified  by  an  asterisk  (*)  along 
side  to  time  segment  containing  the  shifted  task.  The  operator  can 
specify  whether  shifting  will  occur  only  to  an  earlier  time,  by  using  a 
minus  value,  or  to  be  shifted  to  a later  period,  with  a positive  step 
value,  or  to  either.  in  the  event  a shifted  task  is  unacceptable  to  the 
analyst,  it  is  only  necessary  to  rerun  the  Workload  Assessment  Model  with 
controls  which  preclude  the  selection  of  an  undesirable  time  period  for  a 
specified  task. 

WAM  outputs  include: 

1.  Crew  workload  level  versus  mission  time 

2.  Task  activity 

3.  Subsystem  activity 

4.  Mission  scenario  or  segment  summaries 

2. 3. 5. 2 Workload  Assessment  Model  Requirements  Specification 

The  overall  objective  of  the  WAM  is  to  assist  the  human  factors  engineer 
in  analyzing  operator  workload  imposed  on  each  crew  member  assigned  to 
operate  a system.  This  analysis,  as  pointed  out  earlier,  can  entail  a 

number  of  subtle  factors.  It  is  a general  requirement  on  WAM  to  facilitate 

the  analysis  of  any  or  all  these  factors  - at  the  option  of  the  WAM  user. 
Additional  general  requirements  are  listed  below.  These  are  followed  by  a 
list  of  specific  design  requirements. 

o Tiie  Workload  Assessment  Model  shall  compute  operator  workload  data 
according  to  criteria  established  by  the  model  user  and  final 
evaluation  of  alternative  system/operational  concepts  shall  be  made 
by  the  human  factors  engineer. 

o The  input  and  output  formats  for  the  Workload  Assessment  Model  shall 
be  designed  for  ease  of  use  and  interpretation  by  human  factors 
engineers . 

o The  Workload  Assessment  Model  shall  be  consistent  with  CAFES 

objectives  and  shall  be  designed  for  efficient  interface  with  all 
other  CAFES  submodels. 


2. i. 5.2 


(Continued) 


o I'he  Workload  Assessment  Model  shall  provide  flexibility  and  options 
for  by-passing  detailed  or  complex  portions  of  the  model  when  such 
details  are  not  required  or  are  not  warranted  for  a given  analysis. 
This  flexibility  shall  include  the  specification  of  model  input  data, 
o Tite  Workload  Assessment  Model  shall  be  constructed  on  a modular  basis 
For  efficient  model  update  or  future  modification  and  also  to 
fa  ilitate  operational  flexibility. 

The  detailed  structure  of  the  Workload  Assessment  Model  shall  be 
desi/ned  for  growth  potential  to  accommodate  new  types  of  data  and 
parameter  relationships  as  they  become  available. 

Specific  requirements  on  Workload  Assessment  Model  design,  in  addition 
to  these  general  requirements,  are  listed  below: 

o The  Workload  Assessment  Model  shall  provide  means  for  statistical 
evaluation  by  operator  channel  (eyes,  hands,  feet,  etc.), 
o The  Workload  Assessment  Model  shall  compute  averages  and  standard 

deviations  for  operator  workload  variations  during  a specific  mission 
phase.  Mission  phases  are  segmented  into  equal  time  increments  and 
the  workload  per  channel  in  each  time  segment  is  defined  for  each 
crew  member  in  terms  of  percent  time  the  channel  is  active, 
o Channel  workload  inputs  shall  be  computed  automatically,  using  data 

p ir  Meters  common  to  the  Function  Allocation  Model  whenever  possible, 
i.e.:  mission  scenario,  task  execution  times,  mission  time  segments, 
crew  size,  and  operator  allocation  (Figure  A-20) . 
o The  Workload  Assessment  Model  shall  provide  sensitivity  to  operational 
situation  and  automatically  identify  and  tabulate  critical  workload 
periods  when  workload  exceeds  "critical  workload  threshold." 
o The  Workload  Assessment  Model  shall  tabulate  and  plot  (in  histogram 
fern;'  the  following  information  for  each  critical  workload  period: 
i ;u  ■••.stems  an  utilized  during  each  critical  period. 

' i’  1 • ' t not  required  . ) 

■nt  oi  time  each  subsystem  is  used  during  each  critical 
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2. 3. 5. 2 (Continued) 

Which  tasks  are  being  executed  during  each  critical  period. 
(Plot  not  required.) 

Percent  of  time  during  each  critical  period  that  each  task  is 


- Data  items,  above,  for  the  sum  of  all  critical  item  periods, 
o Channel  breakdown  in  Workload  Assessment  Model  shall  include: 

External  vision 

- Internal  vision 
Right  hand 

Lef  t hand 
Right  foot 
heft  foot 

- Cognition 
Auditory 
Verbal 

Summary  data  shall  be  computed  for  the  following  categories: 

- Total  vision 
Total  motor 

Total  communications 


2. 3. 5. 3 


WAM  Application  and  Data 


Data  used  for  examples  and  illustrations  in  subsequent  discussion  reflects 
the  results  from  application  of  WAM  during  this  study  for  the  mission 
scenario  described  earlier  in  this  report,  manual  functions-allocations 
assumptions,  and  manual  development  of  task  time-sequencing  data.  The 
model  was  applied  in  preliminary  evaluation  of  early  concepts. 

The  procedure  for  preparing  data  for  Workload  Assessment  Model  is  as 
follows  (Figure  4-2): 

1.  Utilizing  performance  manuals  and  standard  operating  procedures,  a 

mission  profile  and  scenario  is  prepared  in  which  time,  event,  distance, 
altitude  and  speed  are  sequenced  over  the  entire  mission. 
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2.  3.5.3  (Continued) 

2.  A mission  phase  chart  is  constructed,  dividing  the  mission  Into 
phases  in  which  times  for  each  phase  are  assigned  on  the  basis  of 
operational  experience  and  estimates  from  simulation  studies. 

3.  Task  definition  and  time  allocation  involves  the  assignment  of  task 
names  to  the  procedures  or  events  identified  in  the  previous  step, 
as  well  as  to  the  elements  of  task  analyses  where  available. 

4.  (In  die  basis  of  the  task  definition/time  data,  a mission  phase  time- 
line analysis  is  prepared,  dividing  the  mission  phase  into  six  second 
segments  (or  any  other  time  period  desired)  and  showing  which  tasks 
are  employed  in  each  segment. 

5.  Next  is  the  determination  of  channel  utilization  times  over  the 
mission.  A typical  channel  time  budget  sheet  lists  the  modality 
channels  (visual,  motor/manual,  cognitive,  auditory,  verbal),  type  of 
task,  and  the  number  of  the  designated  task.  The  numbers  contained 
in  the  modality  columns  represent  "channel  utilization"  times,  or 
the  time  in  seconds  that  a particular  channel  is  used  during  one 
mission  time  segment.  This  concludes  the  manual  data  preparation 
and  channel  utilization  data  are  then  keypunched  for  execution  of 
the  Workload  Assessment  Model . 

Application  of  WAM  is  based  on  comparing  time  required  to  perform  a task 
sequence  with  time  available  for  performance  to  establish  a ratio  reflect- 
ing excess  or  negative  Lime  to  perform.  Tiiis  comparison  is  made  for  all 
crew  interface  channels,  .e.,  eyes,  right  hand,  left  hand,  right  foot, 
left  foot,  auditory,  verbal  and  cognition.  When  WAM  receives  the  channel 
workload  data  for  each  time  segment , it  proceeds  to  compute  the  channel 
utilization  in  terms  of  percent  rather  than  in  time  units  (sec.).  For 
instance,  if  each  segment  is  6 seconds,  the  formula  is: 

channel  utilization  (seconds)  ,,  , 
pet  Llizati  — , • - • - - X 100 

o seconds 

Next,  WAM  nputes  averages,  standard  deviations,  and  variances  for 
channel  w ! id  i they  vary  over  ill  the  time  segments  in  each  defined 
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(Continued) 


mission  phase.  For  example,  in  a mission  phase  such  as  target  acquisition 

, • c.  ■ , i , 5 x 60  .. 

lasting,  say,  live  minutes,  the  number  oi  segments  = — y — - = 50  segments 

o 

and  therefore  50  values  of  percent  workload  would  be  input  to  the  computa- 
tion of  averages,  etc.  This  computation  is  repeated  for  each  channel,  each 
operator,  and  each  defined  mission  phase. 


Output  in  the  WAM  program  consists  of  both  tabular  and  plotted  statistical 
summaries.  For  each  crewman,  a table  is  produced  showing  workload  per 
channel  per  segment.  Workload  figures  are  expressed  as  percentages, 
figures  over  100%  indicating  the  existence  of  an  overload  condition,  while 
figures  over  75%  are  taken  as  potentially  degrading  to  performance. 

Computer  plots  utilizing  the  bargraph  and  histogram  techniques  are  avail- 
able to  the  human  factors  engineer  to  compare  workload  per  channel  between 
types  configurations  and  function  allocations.  Histogram  plots  depict  the 
percentage  of  workloading  over  the  various  mission  phases.  Examples  of 
these  plots  follow,  and  are  also  in  the  User's  Guides  (References  24,  26, 
and  28) . 

As  indicated  earlier  WAM  outputs  include  : 

1.  Crew  workload  versus  mission  time 

2.  Task  activity 

3.  Subsystem  activity 

4.  Mission  scenario  or  segment  summaries 

The  first  two  reports  provide  workload  data  for  each  crewman  and  all 
eight  channels  of  activity.  Representative  tabular,  barchart  and  graphic 
outputs  are  shown  in  Figures  2.3-14  through  2.3-32.  These  outputs  permit 
workload  evaluation  by  the  analyst  for  such  questions  as  mission  phase 
loading,  relative  channel  loading  and  potential  overloads.  Workload  time 
history  graphs  (Figures  2.3-18  through  2.3-30)  identify  specific  mission 
time  frames  where  actual  or  potential  overloads  exist.  Undesirable  loading 
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FIGURE  2.3-14:  CREWMAN  WORKLOAD  REPORT 
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FIGURE  2.3-31:  CHANNEL  ACTIVITY  REPORT 
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may  indicate  a need  for  reallocation  of  man-equipment  functions,  or  inter- 
crew man  functions  and  tasks,  or  of  interchannel  tasks. 

Task  activity  identifies  those  time  segments  in  which  the  specified 
channel,  or  average  workload  exceeds  a specified  threshold  value.  In  each 
of  the  time  segments,  the  thieshold  equals  or  exceeds  a specified  value, 
the  entire  list  of  tasks,  by  identifier,  name  and  time  per  channel,  is 
printed  out  (Figure  2.3-31).  This  analysis  identifies  for  the  human  factors 
engineer  the  factors  which  have  contributed  to  the  critical  overload 
situation.  This  allows  the  analyst  to  judge  the  efficacy  of  restructuring 
or  reallocating  tasks  to  improve  operating  procedures. 

Subsystem  activity  can  be  broken  out  and  reported  in  two  separate  reports 
(although  this  was  not  required  or  produced  for  the  analysis  used  as  an 
example  herein).  The  first  identifies  those  activities  associated  witli  a 
given  subsystem  during  a specified  period  of  time.  The  second  prints  out 
subsystem  activity  during  critical  overload  periods  when  individual 
channel  or  average  workloads  equal  or  exceed  a pnussigned  threshold 
level.  The  subsystem  activities  are  generally  oi  interest  during  detailed 
examination  of  small  segments  of  mission  operations,  e.g.  critical  phases 
of  attack  phases  or  weapons  delivery,  or  approach/ landing  portions  with 
unusually  high  workloads  and  concentrated  activities. 

Mission  scenario  outputs  consist  of  a chronological  listing  of  mission 
tasks,  the  time  each  task  is  started  and  the  time  each  task  ends.  A 
partial  listing  is  shown  in  Fi gure 2 . 3-32 . 

The  statistical  calculations  are  a carryover  from  a previous  program 
developed  at  Boeing  named  Workload  Evaluation  of  Cockpit  Crews.  The 
calculations  present lv  •ne  are  the  same  as  for  Workload  Evaluation  of 
Cockpit  C/e  . : '-’eruge  workload  and  standard  deviations  for  each  of  the 

ei,  • ' ann.  I- , cumul  t ive  workl>  id  for  (1)  total  vision,  (2)  total 

motor,  (3)  total  commun ieat ioi  s and  (4)  average  of  the  eight  channels. 
Individual  channel  ivr  .ges  are  defensible  and  useful,  and  some  cross- 
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channel  average  may  be  meaningful.  A user  option  may  be  desirable,  rather 
than  an  overall  evaluation  (e.g.,  combining  eye  and  feet  activity  for 
’’average”  workload). 


2. 3. 5.4 


Workload  Assessment  Model  Relationship  to  Baseline  HFE 
Methodology 


WAM  application  tracks  directly  with  the  manual  procedure  described  with 
the  baseline  process  (and  summarized  briefly  in  introductory  material  early 
in  this  section).  It  adds  considerably  in  quantitative  precision  and  in 
credibility  of  results.  It  also  provides  significantly  improved  appraisals 
for  possible  workload  shifting  through  the  channel  comparisons  - for 
example,  an  overload  for  the  right  hand  might  be  adjusted  by  shifting 
tasks  to  the  left  hand.  Individual  channel  data  are  useful  and  defensible, 
as  are: 

o Average  workload  and  standard  deviations  indicating  load  variations 
during  the  mission  segment  for  each  channel 
o Cumulative  workload  for  total  vision,  total  communication 
o Task  printouts  for  overload  areas,  and 

o Scenario  summary  data 


the  utility  of  averaging  all  eight  channels  may  be  debatable 
does  provide  a better  impression  of  the  net  "loading"  the 
crewman  may  react  to. 


it 


The  main  requirement  for  WAM  refinements  is  in  the  data  area  - to  develop 
a data  bank  of  broadly  applicable  task  times. 


2.  1.6 


Computer  Aided  Design  of  Crew  Stations  (CAD) 


2.  S.6.1  General  Computer  Aided  Design  Concept 

liie  Computer-Aided  Design  (CAD)  model  provides  a set  of  computer  routines 
to  assist  in  various  aspects  of  crewstation  design.  CAD  encompasses  a mix 
of  capabilities  to  be  used  individually  or  collectively  in  the  development 
and  evaluation  of  rewstution  designs.  In  other  words,  the  separate  func- 
tions of  GAO  can  be  applied  somewhat  independently  as  needed  to  support 

si:  tii alar  phase  of  design  development.  For  example,  CAD  can  be  employed 
: or  a crewstation  vision  analysis  in  one  instance  or  a reach  analysis  in 
.mother  instance.  Design  development  status  and  user  operations  for  each 
i AD  function  are  summarized  below:  / 


rows  tat  ion  Geometry  Description 

CAD  will  now  accommodate  a complete  geometric  description  of  a crewstation; 
e . . aircraft  cockpit.  This  capability  is  basic  to  computer-aided  design 
because  a crewstation  configuration  must  first  be  stored  in  a computer 
before  it  can  be  modified,  analyzed  or  otherwise  affected. 

Geometric  aspects  in  a crewstation  are  described  simply  as  lines,  vertices 
of  polyhedrons,  or  conic  sections.  The  CAD  user  assigns  a name  and  then 
defines  a set  of  coordinate  points  or  conic  parameters  to  establish  the 
shape  and  location  of  the  object  in  the  crewstation.  Locations  are  speci- 
fied relative  to  the  overall  crewstation  coordinate  system.  Geometric 
objects  can  be  organized  under  named  subsystems  or  control  and  display 
panels.  '.'he  format  for  data  input  is  consistent  with  the  CAFES  Data 
Management  System  and  it  is  designed  for  maximum  user  ease. 

Crewstation  Coordinates  Conversion 

CAD  has  the  capability  to  perform  transformations  of  coordinate  values 
between  v'ordini  ■ systems,  but  this  function  is  not  of  direct  concern  to 
the  user.  TV  . -e:  is  no  exposed  directly  to  this  function,  i.e.  he  is 

not  | • i ' input  transformation  data  or  commands.  The  function  is 

pro-  i : .in  'e  omputer  for  his  convenience.  For  example,  individual 
controls  ii-.  : i • i > i o«  -Knit  can  be  located  bv  two-dimensional  panel 
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coordinates  rather  than  by  an  overall  three-dimensional  coordinate  system. 
This  feature  can  also  be  used  to  automatically  describe  geometric  items  in 
a different  coordinate  system  if  a user  prefers  to  make  such  a change. 

Crews  tat  ion  Scaling 

Geometric  items  can  be  automatically  scaled  (uniformly  expanded  or  con- 
tracted) inside  the  computer  by  simply  issuing  a scaling  command.  The 
scaling  command  for  CAD  is  expressed  by  the  percentage  increase  or  decrease 
desired . 

Crewstat ion  Tailoring 

CAD  now  provides  the  user  with  the  capability  for  making  selective  changes 
in  a crewstation  geometry  description.  For  example,  an  instrument  can  be 
relocated  or  a panel  reshaped  or  repositioned  by  simply  issuing  a DELETE 
command  for  the  item  of  interest  and  writing  a new  description  for  the  item. 
Changes  inside  the  computer  will  occur  only  for  the  item  being  modified  - 
the  remaining  crewstation  remains  undisturbed.  This  tailoring  function 
allows  rapid  update  of  a crewstation  design. 

CAD  tailoring  also  provides  for  redefinition  of  crewstation  subsystems. 

For  example,  the  user  may  wish  to  build-up  a subsystem  description  by 
piece-meal  definition  of  various  items  and  then  combine  them  later  under 
one  subsystem  (for  easy  reference  in  subsequent  analyses  and  report 
commands).  This  is  accomplished  with  the  simple  REDEFINE  command  followed 
by  a list  of  the  items  to  be  combined. 

Panel_  Space  Allocation/Control  and  Display  Arrangement 

Allocation  of  panel  space  and  arrangement  of  controls  and  displays  is  part 
of  the  current  development.  Initial  development  provides  means  for  easily 
specifying  a detailed  panel  arrangement  or  changes  to  that  arrangement. 

These  means  are  incorporated  in  the  functions  for  crewstation  geometry 
description,  crewstation  tailoring,  and  digitizer  input  of  crewstation 
geometry.  The  allocation  and  arrangement  function  is  further  supported  by 
i the  reach  analysis  and  section  view  features  of  CAD. 

f 
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Vision  Analysis 

CAD  will  now  perform  a crewstation  vision  analysis.  Employment  of  this 
function  for  external  vision  analysis  requires  the  user  to  specify  (1)  what 
geometric  objects  are  opaque;  (2)  What  objects  are  transparent,  and  (3) 
location  of  the  eye  reference  point.  These  are  easy  tasks,  once  the 
crewstation  configuration  has  been  stored  in  the  computer. 

Internal  vision  analysis  is  accomplished  via  same  elements  involved  in  the 
reach  analysis  program,  i.e.:  the  data  structure  for  input  of  vision 
angular  and  distance  limits  is  the  same  as  for  the  reach  envelope  input. 

All  of  the  internal  vision  analysis  requirements  can  be  met  by  appropriate 
operation  of  the  reach  analysis  procedure.  For  example,  locations  of 
vision  distance  limits  on  specified  panel  surfaces  can  be  found  by  inputting 
a constant-reach  envelope  (at  the  fixed  vision  distance). 

Reach  Analysis 

The  CAD  reach  analysis  function  is  now  operating.  When  the  user  specifies 
a reach  envelope,  from  measured  anthropometric  data  available  in  the  litera- 
ture, the  computer  will  (1)  plot  an  instrument  panel  and  designate  points 
that  can  be  reached,  and  (2)  report  in  tabular  form  a distance  comparison 
between  actual  reach  and  specific  panel  locations.  Reach  analyses  for 
various-sized  crewmembers  are  performed  by  specifying  a different  reach 
envelope  for  each  "percentile  size".  Once  a standard  set  of  realistic 
reach  envelopes  are  defined  and  input  to  the  computer,  then  the  user  can, 
at  any  future  time,  simply  command  a reach  analysis  for  any  crewstation 
configuration.  The  only  input  data  needed  to  generate  a reach  analysis 
are  (1)  a selection  of  percentile  size,  (2)  a selection  of  panels,  whose 
geometry  has  been  previously  stored,  to  be  subjected  to  reach  analysis, 
and  (3)  a section  of  reach  reference  point. 
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Crewmember  Escape  Analysis 

CAD  performs  escape  clearance  analysis  and  this  capability  has  been  demon- 
strated by  a sample  problem  exercise  (Reference  28).  In  essence,  this 
function  checks  for  potential  instances  where  a crewmember  would  bump  into 
an  object  as  he  ejects  from  a crewstation.  The  user  supplies  an  escape 
envelope  (Volume  of  space  through  which  the  crewmember  travels)  and  a list 
of  crewstation  objects  to  be  checked.  The  computer  automatically  identifies 
potential  interferences,  degree  of  interference,  and  objects  causing 
interference.  A plan  view  drawing  is  also  produced  in  addition  to  the 
tabular  output. 

Operation  of  the  escape  analysis  feature  is  relatively  simple  and  poten- 
tially can  be  made  even  easier  by  developing  a Crewstation  Geometry  Evalua- 
tion Model  capability  to  generate  escape  envelopes.  Such  a capability 
would  allow  a quick  definition  of  escape  volumes  for  various  sized  crew 
members  and  various  seat  orientations  (ejection  vectors). 

Although  specifically  designed  for  computer-aided  analysis  of  crewmember 
escape  from  an  aircraft  cockpit,  the  escape  interference  feature  can  be 
applied  to  any  problem  of  fitting  a defined  volume  into  a complex  and  con- 
fined crewstation  space. 

Section  Views 

Original  plans  for  CAD  included  provision ' for  computer  plots  of  section 
views.  However,  this  capability  already  resides  in  the  Crewstation 
Geometry  Evaluation  Model  and  a decision  was  made  to  take  advantage  of 
that  feature  when  the  Crewstation  Geometry  Evaluation  Model  is  integrated 
in  CAFES.  The  Crewstation  Geometry  Evaluation  Model  also  provides  per- 
spective views  which  can  be  valuable  for  visualizing  the  overall  crew- 
station geometry. 

For  more  detailed  information  on  design  and  operation  of  the  various  CAD 
functions,  the  reader  is  referred  to  the  User's  Guide  (Reference  28). 


1.  1.8.2 


(Cont inued) 


2.3.6.  1 


(Continued) 


Computer-Aided  Crewstation  Design  Model  Inputs 

Three  modes  of  geometric  data  input  were  exercised  during  initial  CAD 
development:  manual;  digitizer;  and  the  Crewstation  Geometry  Evaluation 
interface.  The  manual  mode  involves  writing  down,  by  hand,  a point-by-point 
description  (e.g.,  from  a design  drawing).  The  digitizer  mode  simply 
involves  laying  crosshairs  on  a drawing  and  pressing  a button  at  appropriate 
locations.  The  CGE  interface  mode  automatically  interprets  geometric  data 
prepared  for  the  CGE  so  that  it  can  be  input  directly  to  CAD.  To  date, 
each  mode  has  been  demonstrated  to  function  properly  and  the  digitizer 
mode  produced  time  savings  of  about  90%  compared  to  the  manual  mode. 

Further  development  of  the  digitizer  mode  could  provide  for  automatic 
formatting  of  geometric  items  into  subsystems,  panels,  etc. 

COMPUTE K AIDED  DESIGN  OF  CREW  STATION  MODEL  OUTPUTS 

Escape  Interference  Analysis 

Crewmember  Escape  Analysis.  A list  of  items  which  penetrate  the  escape 
volume,  including  location  of  penetration,  depth  of  penetration,  name  of 
penetrating  item,  name  of  item  being  penetrated.  A plot  of  escape  inter- 
ference features. 

Panel,  Control  and  Display  Arrangement  Drawings 

Crewstation  Geometry  Data.  Coordinate  location  of  elements  (instruments, 
displays,  controls),  items  (points,  lines,  curves,  planes,  3-dimensional 
surfaces)  panels,  and  subsystems  (within  defined  coordinate  system)  as 
modified  by  crewstation  scaling,  tailoring  and/or  coordinate  conversion. 

Vision  Analysis 

External  Vision  Polars . Location  of  opaque  and  transparent  areas  are  pro- 
vided for  angular  limits  of  + 180°  azimuth  and  + 90°  elevation. 

Vision  Distances  Distances  between  vision  analysis  reference  point  and 
points  on  a panel  surface  are  determined  for  specified  angles  of  azimuth 
and  elevation  or  points  on  the  panel  surface. 
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2. 3. 6.1  (Continued) 

Vision-Panel  Intersection.  Specifies  the  location  of  vision  angular  or  dis- 
tance limits  on  panel  areas  within  the  given  vision  angular  limits  (as  a 
function  of  location  of  origin  for  vision  analysis  reference  point). 

Reach  Analysis 

Reach  Deviations.  Difference  in  distance  between  reach  limits  and  cockpit 
locations  specified  as  plus  and  minus  distances  and  percentage  of  total 
reach.  Provided  for  right  and  left  hands  and  feet  as  a function  of  crew- 
member size  and  location  of  origin  for  reach  envelope  reference  point. 

Reach-Panel  Intersection.  Loci  which  define  the  intersection  between  reach 
envelopes  and  user-specified  instrument  panels. 

The  drawings  and  concomitant  stored  data  on  geometry  not  only  provide  a basis 
for  comparing  candidate  systems,  but  also  provide  the  basis  for  modifying 
the  present  system  for  application  to  a new  or  different  development  system 
with  different  mission  or  crewstation  requirements.  The  historical 
development  of  design  data  and  development  criteria  can  be  readily  pre- 
served by  incorporation  in  a master  storage  and  retrieval  submodel. 

Computer-Aided  Crewstation  Design  Model  Applicat i mis 

Similarly  to  WAM,  CAD  applications  are  simple  and  straightforward.  Outputs 
are  examined  to  determine  if  vision,  reach  intersections,  and  escape 
volumes  are  reasonable  and  acceptable.  Iterative  refinements  are  accom- 
plished as  necessary  to  develop  a suitable  preliminary  design  or  modify  an 
existing  design. 

2. 3. 6. 2 Computer  Aided  Design  Requirements  Specification 

The  specification  for  CAD  is  extensively  long  and  detailed,  so  that  repli- 
cation herein  would  be  excessive.  The  preceding  concept  description  is 
fully  and  directly  responsive  to  the  specification  to  convey  a summary  of 
the  requirements,  A fully  detailed  development  is  provided  in  Reference 
27  and  28. 
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Computer  Aided  Design  of  Crew  Stations  Relationship  to  Baseline 
HFE  Methodology 


Model  elements  for  CAD  of  Crew  Stations  relate  directly  supporting  to  the 
types  of  requirements  described  in  paragraph  2.2.1.10,  Crew  Station  Con- 
figuration Concepts,  Trade-Offs  and  Design.  Referring  to  that  paragraph 
will  make  apparent  the  fact  that  a number  of  additional  elements  might  be 
specified  and  added.  Some  of  the  elements  already  exist  in  CGE  but  might 
be  more  effectively  used  in  CAD  (e.g..  Military  Standards).  Others  that 
will  be  useful  are  under  development  (e.g.,  Crewstation  Assessment  Reach), 
which  will  improve  on  the  Reach  evaluation.  The  overall  process  is  quite 
complicated,  and  could  require  development  of  a separate  baseline  method- 
ology to  define  a series  of  computer  aids  for  detail  design  similar  to  the 
CAFES  series  for  HFE  uses. 

While  manv  other  growth  areas  could  be  readily  identified,  the  key  emphasis 
in  CAD  has  been  to  assure  the  designer  has  maximum  flexibility  to  be 
responsive  to  all  requirements,  trade-offs  and  necessary  compromises. 
Accordingly,  the  model  is  most  extensively  an  aid  for  Layout  Development 
and  Evaluation. 

CAD  provides  for  rearranging  an  existing  crew  station  with  displays, 
controls  and  work  space  arrangement  or  developing  a new  one.  It  features 
the  flexibility  to  be  fully  adaptable  to  any  geometric  shape.  It  includes 
the  ability  to  reflect  appropriate  equipment  space  as  equipment  locations 
are  designated.  it  an  ri.ndilv  provide  the  capability  to  identify  and 
locate  dedicated  panel  it.  i , and  many  other  features  that  might  be  useful 
to  the  designer. 

Three  major  areas  ot  development  would  be  useful  for  CAD: 

1.  A cataloMK  t equipment  dimensions  data  should  be  implemented  at 

an  early  date. 

2.  Invent  i-i/.at  i an  rout  inis  should  be  started  to  incorporate  the 

vnr  tnstr. tints  that  are  integrated  by  the  designer  in  relating 

standard  . irea  layout,  usage  characteristics,  and  criticality. 
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Crewstaticm  Geometry  Evaluation  (CGK) 


The  process  of  incorporating  this  model  in  CAFES  is  presently  in  progress. 
Related  activities  will  provide  a more  current  ability  to  produce  informa- 
tion relevant  to  the  present  study.  Accordingly,  this  section  provides 
an  initial  summary,  with  more  detailed  data  to  result  from  the  integration 

process . 

2. 3. 7.1  Crewstation  Geometry  Evaluation  Concept 

The  Cockpit  Geometry  Evaluation  Computer  Program  System  is  designed  and 
developed  to  be  a computerized  anthropometric  evaluation  tool  available 
from  the  conceptual  phases  of  crew  station  design.  The  heart  of  the 
evaluation  method  consists  of  a three-dimensional  man-model  (BOEMAN) 

(See  Figure  2.3-33)  that  synthesizes  joint  locations  and  orientations 
as  it  simulates  human  movement.  It  can  indicate  and  help  resolve  physical 
incompatibilities  between  any  sized  crew  member  (in  percentiles)  and  the 
given  crew  station  design  beginning  with  the  conceptual  phases  of  product 
development.  it  appears  that  the  concept  may  be  flexible  enough  to  be  modi- 
fied in  the  future  to  serve  as  a computer  aided  design  tool  as  well  as  an 
j evaluation  tool. 

< 

The  Crewstation  Geometry  Evaluation  Computer  Program  System  is  a sequential 
set  of  FORTRAN  IV  programs  for  the  CDC  6600/CYBER  74  that  provides  the 
capability  to: 

1.  check,  transform  and  store  large  and  varied  amounts  of  data, 

2.  retrieve  selected  subsets  of  data;  calculate  body  joint  locations 
of  the  man-model  as  it  simulates  task  performance, 

3.  calculate  selected  numerical  performance  indicators, 

4.  determine  whether  the  tasks  are  within  the  reach  capabilities 
of  any  sized  pilot  under  various  restrained  conditions, 

5.  detect  visual  or  physical  interference, 

6.  attempt  to  correct  for  visual  interference,  and 


2. 3.7.1 


(Cont inued) 


7.  avoid  physical  interference  caused  by  straight  line  hand  trajectories, 
independently  check  crew  station  compliance  with  selected  military 
standards.  These  capabilities  are  an  outgrowth  of  the  requirements 
placed  on  the  program  during  Phases  I,  I1A  and  HI  as  well  as  various 
assumptions  made  in  order  that  an  operational  evaluation  tool  would 
resu  1 1 , 

2.  1.7.2  Design  Requirements  and  Features  for  Crewstation  Geometry 

Evaluation  Model  Development 

T’ne  Crewstation  Geometry  Evaluation  Model  program  requirements  and  their 

relation  to  or  effect  on  the  Crewstation  Geometry  Evaluation  Computer 

Program  System  consist  of  the  following: 

1 . To  establish  a common  reference  system  to  evaluate  the  physical 
compatibility  of  an  operator/crew  station  layout.  In  the  program, 
three  relatable  reference  systems  are  used.  The  first  is  a design 
coordinate  system  (using  buttock,  water  and  station  lines).  Data 

on  cockpit  geometry  plane  vertices  and  control  locations  are  expressed 
in  this  reference  system  initially  from  crew  station  drawings.  These 
an  hecked  and  transformed  to  a Euclidean  coordinate  system  (x,y,z) 
whose  origin  coincides  with  the  cockpit  eye  reference  point.  These 
data  art  then  stored  and  made  available  for  an  evaluation  run.  At 
tho  beginning  of  each  evaluation  run,  BOEMAN's  eye  midpoint  initially 
coincides  with  the  eye  reference  point  origin.  The  data  are  again 
transformed  so  that  the  origin  corresponds  to  the  specified  sized 
BOEMAN's  seated  position.  The  design  coordinate  system  is  necessary 
because  the  data  are  given  in  that  system.  The  other  two  systems  are 
used  because  the  lumbar  joint  location  (and  hence  the  seat)  are 
dependent  upon  BOEMAN's  link  dimensions  if  the  eye  midpoint  is  to  be 
at  the  eye  reference  point. 

2,  To  prod  ret  ;tat ton  evaluation  results  regardless  of 

the  inv<  tijpu  r.  . p ; table  results  depend  on:  universal  availability 
<<;  tnd  ..all-defined  procedures  for  generating  the  anthropological, 

,■’<)  flight  mission  data;  consistent  application  of  the  model 
in  r>  m : > * p iz<’  luring  a task  sequence,  error  hounds,  weighting 
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coefficients,  and  preferred  angles  (all  of  these  relate  to  the 
objective  function  and  to  the  entire  optimization  procedure  used 
to  synthesize  BOEMAN's  motion);  relative  insensitivity  of  the  model 
to  differing  initial  conditions  brought  about  by  utilizing  a 
different  computer. 

3.  To  permit  crew  station  evaluations  to  be  accurately  performed  using 
an  acceptable  amount  of  time  and  expense.  Hand  joints  with  respect 
to  the  control  locations  are  calculated  with  tolerance  limits  of  0.7 
inch.  Currently,  on  the  basis  of  CDC  6600  computer  time  required  to 
process  a seven  task  sequence,  joint  position  calculations  and  body 
segment  locations  (up  to  14  positions  per  task)  require,  on  the 
average,  less  than  2 minutes  of  central  processor  (CP)  time  per  task. 
This  can  be  further  reduced  significantly  by  decreasing  the  number  of 
intermediate  positions  required  in  tasks  of  relatively  small  distance, 
for  example. 

4 . To  permit  specific  items  that  interfere  with  crew  movement  to  be 

id entified  and  indicate  areas  where  improvement  is  mos t beneficial. 

The  program  uses  bounded  cockpit  planes  and  planar  approximations 
to  the  body  segments  of  BOEMAN  and  tests  each  of  them  for  the  occur- 
rence of  visual  interference  with  the  line  of  sight  at  the  end  of 
each  task.  If  visual  interference  occurs,  a correction  procedure 
is  used  to  move  the  man-model  to  avoid  the  blocking  plane (s)  if  he 
can  feasibly  do  so.  Physical  interference  of  body  segments  with  each 
other  or  with  the  crew  station  is  identified  and  its  extent  and 
importance  are  assessed.  Physical  interference  correction  is  handled 
partially  by  avoiding  interference  of  objects  with  the  hands  and/or 
feet  as  they  travel  towards  their  specified  control  points. 

5 • To  permit  the  evaluator  to  consider  dynamic  motion  with  real  time 

effects,  variations  in  operator  size,  simple  and  complex  action  and 
physical  restraints.  Presently  the  Cockpit  Geometry  Evaluation 
Computer  Program  System  utilizes  task  data  that  simulates  the  duration 
"of  a human  motion  and  the  generated  positions  correspond  to  this  time 
interval.  The  individual  length  and  mass  percentiles  of  the  body 
segments  are  user  specified,  providing  for  size  and  weight  variations 
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of  Che  operator.  Physical  restraints  such  as  lap  belts  or  shoulder 
harnesses  are  currently  provided  for  by  restrictions  on  the  angular 
limits  of  pertinent  joints  in  the  upper  torso. 
b . To  produce  results  in  a form  applicable  to  either  program  management 
or  design  development  decisions.  The  program  produces  a printed 
history  of  a flight  mission  portion  (or  task  sequence)  for  evalua- 
tion. There  are  user-controlled  options  available  to  vary  the  size 
and  content  of  the  output  depending  on  the  purpose  of  the  evaluation. 
The  options  include  suppression  of  any  or  all  input  data,  and  expan- 
sion of  the  processing  and  summation  sections.  The  system  automati- 
cally provides  for  a minimum  of  printout  when  a task  is  performed 
feasibly.  A summary  of  the  evaluation  run  is  also  provided  which 
reports  the  number  of  times  a body  system  (e.g.,  upper  torso,  arms, 
feet,  and  head)  had  to  move  during  the  task  sequence  and  provides  a 
list  of  infeasibility  conditions  generated  during  the  sequence. 

7 . To  provide  a method  for  validation  of  the  mathematical  man -model  and 
Crews  tat  ion Geometry  Evaluation  Computer  Program  System.  The  vali- 

dation in  which  comparisons  of  man-model  and  human  paths  of  motion 
are  analyzed  is  discussed  in  the  validation  Document  (Reference  12). 
Isis  consisted  of  an  evaluation  of  the  cockpit  of  the  A7E  fighter 
lircraft  using  the  Crewstation  Geometry  Evaluation  Computer  Program 
S tern  to  determine  if  problems  known  to  exist  with  this  crew 
station  were  detected  by  the  Crewstation  Geometry  Evaluation  Computer 
Program  Svstem  and  whether  other  unreported  problems  also  exist.  The 
results  of  the  A7E  evaluation  are  discussed  in  Volume  I of  the  Phase 
III  final  report  (Reference  17). 

Inputs  to  Crewstation  Geometry  Evaluation  Model 

The  input  required  includes  initial  and  final  joint  locations  during  the 
task,  cintr  . r t • os  ..nd  mass  lor  each  link,  task  control  locations, 

and  initial  ; i anrul'ui  and  position  values.  The  joint  location  and 
orientation  ;ri a vs,  and  the  constraint  vectors  are  reset  for  the  next 
task  with  Bn  AN'  i current  orientation  and  position. 
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from  Crews tat  ion  Geometry  Eva luat ion  Model 


Program  OUTGO,  the  output  overlay,  provides  for  a printed  history  of  the 
evaluation  run,  data  for  graphs  and  charts,  and  an  optional  tape  for  the 
validation  section.  The  printed  history  is  divided  into  four  parts: 

1.  Input  data 

2.  Results  of  task  sequence  processing 

3.  Summation  data 

4.  Summary  of  task  sequence 

Summation  data  include  the  numerical  performance  indicators  calculated  in 
the  previous  overlay  (Program  SUMM) . The  data  required  for  validation 
include  BOEMAN's  joint  locations  during  each  step  of  a task  for  which  com- 
parable laboratory  data  exist.  The  task  sequence  summary  consists  of  a 
table  of  the  number  of  movements  of  each  Body  system  and  a summary  of 
infeasible  tasks  during  the  sequence. 


The  printed  history  is  generated  using  the  intermediate  output  file  along 
with  control  variables  (user  specified)  which  determine  the  amount  and  kind 
of  history  required  for  the  evaluation. 
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Human  Operator  Simulation  (HOS) 

Detailed  CAFES  interlaces  with  the  Human  Operator  Simulation  are  in  initial 
exploratory  phases.  Accordingly,  this  section  is  mostly  descriptive  in 
nature. 

-1 . 1.8.1  Central  Human  Operator  Simulation  Concept 

live  Human  Operator  Simulation  Model  is  currently  under  development  at  NADC 
and  i-  not  . rrently  part  of  the  CAFES  system  library.  The  date  of  intro- 
■ 1 1 l i 't  > cl  to  be  defined  (Reference  39). 

i .c  Hu. ran  Operator  Simulation  Model  is  a generalized  computer-driven  model 
'■  u Human  Hi  ing  in  a goal-oriented  task  processing  environment.  The  model 
been  nnd.  r development  over  the  past  several  years  to  enable  simulation 
■i  hum.i1  operator  functions  in  weapons  systems  as  realistically  and  accurately 
as  the  t unctions  ot  weapons  systems  are  simulated  by  models. 

Those  human  operator  simulations  attempted  to  date  show  progress  toward 
attainment  of  the  realism  and  accuracy  necessary  to  replace  the  human  with 
tlie  simulator.  Normal  task  analyses,  for  example,  leave  one  with  the 
impression  that  a human  operator  serially  processes  all  steps  in  a parti- 
cular task  as  if  this  were  the  only  one  he  had  to  perform.  This  approach 
ignores  the  dynamic,  adaptive  character  of  actual  human  behavior.  In 
reality,  the  operator  is  usually  processing  a variety  of  more-or-less 
independent  tasks  simulataneously  (e.g.,  maneuvering  aircraft  and 
searching  visually  lor  targets  while  monitoring  instructions  'Trum  t lie 
Forward  Air  Controller).  (ask  analyses  fails  to  indicate  what  factors 
determine  when  he  stops  working  one  task  and  begins  to  work  on  another. 

Such  techniques  yield  oversimplifications  on  the  role  of  the  operator, 
thus  providing  questionable  operator  workload  information.  This  is  not 
to  indicate  t lie  task  analyses  is  useless  or  not  effective.  On  the  contrary, 
a task  at*.!  I>.  Oi's  result  in  familiarity  with  the  system  and  often 

reveal,  nan  rt  nl  g.  it. a area:  of  probable  difficulty. 
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2.3.8  (Continued) 

The  method  of  entering  data  and  the 
examined.  A special  Human  Operator 
developed  to  enable  users  of  HOS  to 
the  system  and  mission  instructions 
statements  are  "compiled"  by  HAL, 
output  of  HAL  is  then  input  to  HOS. 
pseudo-machine  instructions  produced 
closely  analogous  to  the  logical 
tiie  same  task,  and  the  data  it 
analyses  as  are  performed  on 


machine  language  to  be  used  has  been 
Procedures  Language  (HOPROC)  has  been 
input  both  operating  procedures  for 
English-like  statements.  HOPROC 
HOPROC  Assembly /Loader  program.  The 
HOS  operates  as  a processor  of  the 
Its  logical  processes  are 
of  a human  operator  performing 
is  amenable  to  the  same  type  of 
human  experiment. 


in 
t lie 


by  HAL. 
processes 
produces 
data  from  a 


HOS  has  four  principal  program  modules:  The  Decoder,  the  Multiplexer,  the 

Estimator  and  the  Banker. 

2. 3.8. 2 Program  Modules 

The  Decoder  is  analogous  to  the  human  understanding  and  decision-making 
function.  It  receives  an  instruction,  comprehends  it,  and  decides  what 
further  information  and  actions  are  necessary  to  accomplish  it.  It  then 
initiates  the  necessary  steps  to  obtain  the  information  or  perform  the 
actions.  This  may  involve  the  initiation  of  a new  procedure  when  a display 
or  control  must  be  "enabled"  before  it  can  be  used.  It  may  require  calls 
to  the  Estimator  to  obtain  the  estimated  value  of  the  device,  to  the 
Anatomy  Mover  to  prepare  the  body  for  performing  an  action,  or  to  the 
Control  Manipulation  Section  of  the  processor.  The  Decoder  thus  determines 
what  is  needed  and  how  best  to  sequence  actions  in  order  to  accomplish  it. 
It  also  determines  whether  a procedure  can  be  continued.  When  a particular 
action  cannot  be  performed  immediately,  it  calls  the  Multiplexer  to  select 
another  procedure  to  be  executed. 


The  Multiplexer  is  the  module  that  decides  which  procedure  should  be 
handled  next  by  the  Decoder.  It  establishes  priorities  among  possible 
procedures  and  generates  interrupts  when  an  alteration  in  the  instruction 
sequence  is  necessary.  The  Multiplexer  can  be  called  for  any  of  three 


reasons : 
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2. 3. 8. 2 (Continued) 

1.  If  the  sequence  of  instructions  constituting  a procedure  is  completed, 

2.  If  an  instruction  is  executed  which  permits  the  selection  of  a new 


procedure,  or 

3.  If  an  action  in  a procedure  cannot  be  completed. 

The  Multiplexer  selects  a new  procedure  by  scanning  the  list  of  available 
procedures  and  selecting  the  one  with  the  highest  criticality.  If  none  are 
sufficiently  high,  the  Multiplexer  may  either  return  to  the  procedure  that 

was  being  executed  or  enter  a "relax"  mode  in  which  physical  and  mental  j 

conditions  will  be  reflected  in  improved  O-state  levels.  O-states  are 

parameters  which  describe  the  individual  operator's  current  capability  to 

perform  certain  classes  of  operation.  These  may  be  permanent  (such  as 

basic  ability)  or  transient  reflecting  physical  or  mental  fatigue. 

Transient  components  of  O-states  will  vary  as  a function  of  work  and 
relaxation  cycles. 

. 

i A second  type  of  interrupt  is  generated  by  hardware  conditions  that  may 

affect  the  sequence  of  a run,  such  as  the  appearance  of  a warning  light. 
f Such  events,  however,  may  not  affect  the  operator's  actions  immediately. 

An  Interrupt  Detector  in  the  Banker  determines  the  likelihood  that  the 
change  in  the  hardware  state  will  be  noticed  by  the  operator  as  a state 
which  critically  requires  his  attention. 

The  third  type  of  interrupt  occurs  when,  for  example,  the  simulated  operator 
requires  his  left  hand  to  activate  some  device  but  he  is  currently  using 
his  left  hand  to  adjust  another  control.  The  current  procedure  will  be 
terminated  and  a scheduled  interrupt  arranged  for  when  the  left  hand 
becomes  free  to  be  used  by  this  procedure.  In  the  interim  the  operator 
\ may  work  on  other  tasks. 


The  Estimator  is  the  sens  ing/ remember  ing.  core  of  HOS . It  also  determines 
the  time  costs  for  performing  certain  actions  and  for  absorbing  information. 
For  instance,  following  a decision  to  set  a knob  at  0.5,  the  Estimator 
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2. 3.8. 2 (Continued) 

might  determine  that  it  will  take  0.8  seconds  to  absorb  the  information  on 
the  present  position  of  the  knob  and  1.1  seconds  a accomplish  the 
knob-turn  action. 


The  Estimator's  function  closely  simulates  a human  being's  actions  in  that 
its  operations  are  not  fully  deterministic.  The  three  kinds  of  actions 
are: 

1.  Preparation  for  information  gathering,  such  as  moving  eyes  to  display, 

2.  Information  absorption,  such  as  recognizing  the  value  indicated  on 
the  display,  and 

3.  Control  actuation,  such  as  position  of  a lever. 

Before  performing  a control  actuation  action,  the  operator  checks  to  see 
if  the  action  is  necessary  — whether  the  control  is  already  in  the 
desired  position.  If  it  is,  the  action  will  not  be  taken. „ The  check  is 
performed  by  means  of  a sequence  of  information  gathering  actions  on  the 
value  of  the  current  control  setting. 


Information  gathering  is  a four  stage  process.  First  if  the  operator  is 
already  "in  contact"  with  the  display  or  control  of  interest,  he  will 
absorb  its  value.  Second,  if  he  is  not  in  contact  witli  the  device,  recall 
is  attempted,  which  if  successful  entails  only  a small  time  cost.  If 
recall  is  not  immediately  possible,  but  still  highly  probable,  the  operator 
is  allowed  additional  time  to  attempt  recall.  This  results  in  the  accumu- 
lation of  additional  small  time  charges  until  it  is  decided  either  that 
the  value  can  be  remembered  or  that  recall  has  failed. 


The  success  of  any  recall  attempt  is  probabilistic,  depending  on: 

1.  The  time  since  the  previous  observation,  t 

2.  The  hab  strength,  H 

3.  The  short  term  memory  capability,  and 

4.  A confidence  level,  which  reflects  the  operator's  willingness  to 
believe  his  own  memory,  and  is  the  reference  against  which  the 
probability  of  recall  is  tested  for  success. 
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the  Banker  accumulates  time  charges  for  all  actions  performed  by  the 
operator  and  serves  as  the  interface  with  the  hardware  simulator.  When 
a numerical  value  of  a display  reading  or  a control  setting  is  required, 
the  Banker  acquires  it  from  the  hardware  simulator,  which  may  be  either  a 
data  file  or  a hardware  simulation  program  module  containing  the  equations 
governing  hardware  response  to  control  manipulations. 


Charges  also  accrue  in  terms  of  aphysiological  change  (eye  strain,  muscle 
fatigue,  etc.),  reflected  by  changes  in  O-state  value  over  time,  although 
the  Banker  is  only  concerned  with  time  charges. 


The  output  from  the  simulator  is  a printout  of  information  messages  as  each 
instruction  is  executed  and  whenever  a significant  event  occurs.  The  user 
may  also  define  certain  processing  points  as  milestones.  When  the  mile- 
stone is  reached,  the  data  arrays  associated  with  the  displays,  controls 
and  functions  are  printed  out. 


The  simulator  also  dumps  the  relevant  data  to  a magnetic  tape  or  disc  for 
use  by  the  Human  Operator  Data  Analyzer/Coliater  (HODAC) . HODAC  reduces, 
formats  and  analyzes  the  data.  The  types  of  analyses  which  can  be  done 
include : 


o 

Display  and  Control  usage  — 

including  time  spent  accessing  informa- 

tion,  absorbing  information. 

and  monitoring. 

o 

Mediated  function  usage  — including  time  spent  estimating  and 
calculating. 

o 

Anatomy  movement  and  memory. 

o 

Loading. 

o 

Procedural  utilization. 

o 

Monitoring  frequencies. 

o 

Interrupts . 

The  results  of  these  analyses  can  be  compared  with  mission  scenario  simu- 
lations, hardware  and  weapons  systems  simulations.  These  comparisons  can 
be  used  to  a,  t ■ . i ::  im  whether  the  events  that  transpired  during  an  engagement 
were  acceptable  iron  both  a human  factors  and  an  operational  point  of  view. 
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o Baseline  Concept 

The  structured  method  developed  herein  to  outline  a baseline  methodol- 
ogy for  HFE  processes  provides  for  a logical  and  feasible  sequencing 
of  activities  to  support  a system  development  program.  With  some 
additional  effort,  the  baseline  could  be  extended,  organized,  and 
documented  to  provide  a reference  source  for  broader  applications 
which  could  draw  more  heavily  and  systematically  from  past  experience 
for  new  development  programs.  This  reference  source  would  be  useful 
in  assuring  improved  consistency  in  HFE  products  between  programs  and 
in  manual  HFE  efforts,  as  well  as  providing  a structured  format  for 
CAFES  uses.  In  either  case,  it  would  help  to  minimize  attention  to 
routine  activities  in  order  to  concentrate  more  extensively  on  those 
activities  that  are  unique  to  a present  system  development. 

Most  appropriate  follow-up  relative  to  this  subject  area  would  be  to 
extend  the  baseline  process  developed  during  this  study  to  cover  an 
entire  mission.  Such  a development  should  emphasize  the  systematic 
progression  of  analytic  indenture  to  distinguish  functions  that  are 
common  to  a system  (e.g.,  aircraft)  to  a system  type  (e.g.,  fighter) 
and  to  specific  variations  in  missions  (e.g.,,  reconnaisance , close 
support,  air  to  air  combat). 

o CAFES  Compatibility  with  the  Baseline  HFE  Process  and  General  Needs. 

In  general,  CAFES  submodel  features,  operations  and  requirements  are 
compatible  with  the  baseline  process  developed  herein.  Some  refine- 
ments are  desirable,  most  specifically  with  regard  to  improving  user 
interface  operations  and  interpretations. 

A substantial  effort  still  remains  in  the  development  of  the  CAFES 
system.  The  Computer  Aided  Crewstation  Design  Model  is  yet  to  be 
completed.  The  Crev/station  Geometry  Evaluation  and  the  Human  Operator 
Simulation  Model  are  yet  to  be  made  compatible  with  the  Data  Manage- 
ment System  so  that  all  submodels  can  utilize  and  interchange  input 
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ami  output  information.  Until  this  effort  is  accomplished,  more 
extensive  Involvement  of  the  HFK  will  be  required  to  effect  the 
interchange . 

Verification  and  validation  of  CAFES  submodels  requires  additional 

testing  and  use  on  both  current  and  developmental  systems.  Sensitivity 

and  ability  of  each  submodel  to  discriminate  significant  differences 

have  yet  to  be  demonstrated.  The  influence  of  data,  i,e.,  human 

operator  reliability,  equipment  reliability,  task  performance  time, 

etc.,  has  yet  to  be  established  for  both  absolute  and  relative  rankings 

of  candidate  crew  system  configurations. 

\ 

A User's  Guide  to  human  factors  engineering  tasks,  based  on  specific 
examples  from  previous  systems  developments  is  required  to  minimize 
required  effort  and  to  provide  an  efficient  means  to  train  personnel 
in  the  methods  employed  in  human  factors  or  crew  systems  analysis. 

o General  Data  System  Development  Need 

Detailed  development  of  a structured  data  system  concept  (i.e.,  an 
information  system)  is  needed  to  provide  for  more  effective  data 
organization,  storage,  retrieval,  integration  and  use.  Properly 
structured,  such  a system  could  significantly  enhance  access  to  that 
minimum  but  sufficient  level  of  detail  necessary  for  HFE  applications. 

> 

This  information  system,  built  for  a baseline  methodology  such  as  is 
reported  herein,  could  significantly  reduce  or  eliminate  the  need  to 
start  and  develop  new  data  sets  for  each  new  system  development 
or  modification  to  come  along.  With  the  systematic  framework  pro- 
vided, and  data  updates  maintained,  appropriate  information  would 
be  more  readily  accessible  and  usable  throughout  a research,  develop- 
ment, ti.-t  and  evaluation  program. 


1 a 

:i-  an  nformation  system  is  considered  highly  desirable  lor  manual 
analyses,  and  essential  for  the  CAFES  Data  Management  System  (DMS) . 


(Continued) 

A carefully  developed  structure  for  access  to  HFE  data  will  have  a 
significant  influence  in  minimizing  computer  time  and  costs  for  data 
search  in  the  DMS . Present  formatting  is  compatible  with  the  proposed 
concept;  it  remains  to  develop  the  information  system.  In  all  likeli- 
hood, this  development  can  be  most  effective  if  accomplished  to 
p:irallel  or  follow  extension  of  tfie  baseline  process  to  encompass  a 
total  system  concept.  At  a minimum,  the  resulting  information  system 
structure  would  be  more  appropriately  postured  for  system  development 
needs . 


General  CAFES  Applicability 

CAFES  related  analyses  or  submodels  applications  are  not  limited  to 
airborne  weapons  systems.  Applications  are  currently  being  evaluated 
which  are  concerned  only  with  HFE  applications  in  handling  of  ground 
based  equipment  and  materials  that  are  completely  divorced  from  either 
the  airborne  system  or  its  support  equipment.  Such  applications 
include:  ground  handling  and  sorting  systems  for  postal  envelopes 
and  packages;  the  distribution,  disbursement,  and  monitoring  of 
airport  passenger  traffic  in  terminal  areas,  and  fire  department 
monitoring,  disbursement,  and  control  of  fire  fighting  men  and  equip- 
ment leading  to  training  requirements.  The  potential  list  is  almost 
limitless  since  man  is  included  in  most  systems  as  an  information 
processor,  decision  maker  and  control  actuator  in  response  to  the 
information  processed. 

Specific  CAFES  Related  Developments  or  Refinements 
Information  or  data  that  can  be  stored  to  facilitate  HFE-CAFES 
operations  follow: 

Mission  Requirements 

Outline  of  system  operational  requirements 
Outline  of  mission  scenario 
- Mission  profile  data 
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Functional  Flows 

System  common  functions  (all  aircraft) 

System  type  functions  (e.g.,  fighter) 

Mission  peculiar  functions 

- Task  types:  visual  - motor  - cognitive  - auditory  - verbal  - other 

Task  action  elements 

Quantitative  task  features:  time  - accuracy  - reliability 
Qualitative  task  data:  pilot  commentary  - trade-off  precautions  ~ 

related  hazard  or  accident  potential 

Task  characteristics  and  weighting  information:  task  criticality 
ratings  - task  priority  ratings  - task  adjustment  data  (mission 
stress,  time  compression)  - task  load  rating 
Reference  topics  or  sources 

Equipment  Data 

Physical  characteristics:  dimensions  - weight 
Performance  characteristics:  parameters  - accuracy 
Operator  interface  characteristics:  interface  features  - tasks  - 
task  data  as  above 

Application  characteristics:  reliability  - cost 

Location  constraints:  mandatory  location  - mandatory  arrangement  - 
mandatory  access  zones  - options 

- Use  constraints:  pilot  commentary  - unsatisfactory  reports  - other 


Other  Data 

- Human  anthropometry 
Life  support  data 

- Other 


Additionally,  more  ipecific  CAFES  model  features  are  summarized  in 
Table  3- 1 . 
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APPENDIX  A 


DETAILED  TABULATION  OF  REPRESENTATIVE  FUNCTION-ACTION-INFORMATION 
REQUIREMENTS  FOR  RECEIVER  REFUELING 

This  appendix  sunsnarizes  a detailed  development  of  function  action- 
information  requirements  for  one  possible  mission  segment  for  • receiver 

vehicle-airial  refueling.  The  summary  is  presented  as  an  example,  to 
show  how  such  information  might  be  developed.  More  extensive  detailing 
of  indentures  is  readily  achievable  if  more  specific  implications  for 
control-display  requirements  are  desired. 
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